Thanks @ben.boeckel. And sorry for the delayed response.
Indeed it looks I may not be able to pull this off in single invocation of CMake. However, I found that there are a number of variables that I can use, but they are unfortunately a deprecated means of achieving what I want (according to the documentation).
This comment by @brad.king on the issue tracker referenced in this StackOverflow answer contains part of the answer and it’s not the answer I’d like 
… but mentions those variables (CMAKE_C_COMPILER_ID_RUN, CMAKE_C_COMPILER_FORCED and CMAKE_C_COMPILER_WORKS). I haven’t found a modern alternative, though. And since CMake doesn’t seem to make a distinction of “internal” and “external” variables (like the leading _ in vendor-specific C++ extensions or similar) it’s tough to come up with a robust approach here.
Either way, I am currently trying to get around this by scripting my way through the initial compiler build a bit and gluing that together with the CMake part. For my investigation (this was Clang/LLVM all the way), I found a Fuchsia-related article (which I cannot link to because new users may only use two links at most 
) extremely helpful. It opened my eye to all these .cmake files inside the source tree (under the clang subfolder) which are passed via -C to CMake and pre-populate the CMake cache a certain way.
Thanks for the input, it’s much appreciated.