Yes, DNX compares pretty well to Mono’s mono.exe. Or for that matter the runtime of other VM languages like Java (java.exe) or Python (python.exe). They all solve the same chicken-and-egg problem, they run on operating systems that don’t know beans about the VM. It has to be initialized first, the program’s entry point needs to be located and the Main() method needs to be jitted before your program can start running.
One small difference in DNX with these other VMs is that it keeps the CLR and the jitter still in a separate library, coreclr.dll. The other ones are monolithic with all the runtime support code compiled into a single exe. Keeping it monolithic improves cold-start performance. Probably something that will happen with dnx as well, once CoreCLR stabilizes and doesn’t have umpteen different beta releases.
This otherwise follows the architecture of .NET on Windows, it is c:\windows\system32\mscoree.dll that bootstraps the CLR. And the CLR and jitter are separate DLLs, clr.dll and clrjit.dll for .NET 4.x. Mscoree uses significant trickery and deceit to make it look like you can start a managed program from a single EXE file. Particularly the trick to create a 64-bit process from a 32-bit EXE file is heroic, it patches internal operating system loader structures to accomplish that feat. This requires Windows itself to be aware that an EXE contains managed code. Trickery that does not translate well to other operating systems like Linux and OSX so they decided for the more conventional way for CoreCLR.
Update: DNX is now deprecated and replaced by DOTNET. Otherwise without invalidating this post content, just easier to use.