It is a big topic with very gritty implementation details. Hard to address them all, but there are some misconceptions in the question. Let's address those, might help to get to next stage.
Moreover, how is it able to use .NET assemblies (which are CIL)?
Not just CIL, the linker produces a mixed-mode assembly. Contains both .NET metadata + msil and native code. In fact, as far as the OS loader is concerned, it is the native code in the executable file that is normal. No different from the kind produced by a native C++ compiler. It gets loaded and relocated just like a pure native executable image. It is the .NET metadata + msil that is the oddball. To the loader it just looks like a chunk of data, it doesn't touch it at all. Only the CLR does.
... use Standard C++ code (which isn't compiled to CIL)
Not quite accurate, native C++ code can be compiled to msil or machine code. What you get depends on whether the /clr compile option was used or the #pragma managed that was in effect at the function level. CIL does not compare that well to, say, the bytecode used in the Java JVM. It is more powerful and can support any C++03 compliant native C++ code. Sometimes you do this on purpose to take advantage of reverse pinvoke (native code calling managed code). Sometimes it is done by accident and entirely too much native C++ code gets compiled to msil. The machine code produced by the jitter is not as optimal (it optimizes under time constraints) and is not managed in any way. It is not verifiable and doesn't get garbage collector love.
Best mental image for CIL is as the Intermediate Representation that is used in any native C++ compiler between the front-end (parser) and the back-end (code-generator and optimizer). Often an invisible implementation detail but gets more visible when you use a C++ compiler that uses LLVM (like Clang does). The .NET just-in-time compiler does at runtime what LLVM does at compile time.
Most programmers have the mental image of a giant mode switch being thrown when managed code calls native code (or the other way around). That is not accurate at all. You might want to take a look at this post, shows the difference between machine code produced by the C++ compiler's back-end and the jitter. Key is it is almost identical, an essential feature to ensure managed code is competitive with native code. Helps to clarify how managed code calling native code, or the other way around, is not that special.
Another misconception is that managed code is automatically safer. Not quite true, a language like C# lets you party with pointers and scribble around on the stack just like you can with C++ and you can corrupt memory just as easily that way. It is just partitioned better, it forces you to be explicit about it with the unsafe keyword. No such constraints on C++/CLI, anything goes.
The essential difference between managed and native code is a data structure that the jitter generates when it compiles msil. Extra data you don't get from a native compiler. That data is required by the garbage collector, it tells it how to find object roots back. More about that data in this post. Having to conform to that data and allowing the GC to get its job done is what makes managed code a bit slower at runtime.
