Unity is an engine where the scripting portion is Mono based, upon export it is converted into C/C++/Obj-C/Java for Desktop/mobile/web platform of choice. It will be similar for javascript, the exported asm.js supported javascript will emit from the export to WebGL.
Unity runs in the native platform it is in but Mono is their 'scripting engine' and part of their core engine much like UScript/UnrealScript is UDK's scripting engine. Unity uses Mono a little deeper than that but the resulting export is optimized for the platform it exports to. Since it is built on .NET it is alot like LLVM/JVM languages in that the IL/CLR/DLR are used to export all common languages used in scripting to a common output and this is also the reason you can use C#/Javascript/Boo (Mono versions) as they export to the same thing in the end native to the platform they are on.
I am sure there will be pluggable areas of the outputted javascript but for the most part you'll develop it as usual in Unity and won't mess with the output as much except to plugin third party toolkits etc.
Unity didn't say that 100% of Unity features will be supported in WebGL. Some scripts will, most likely, not be able to run in the WebGL builds initially. Also... Things like GI, or the new PhysX... I wouldn't count on if you are wondering how to prepare a game to be WebGL ready.
That said, I'm certain they will improve the WebGL build tech as time goes on, and eventually MOST of what anyone would need will be available. It just won't be available on day 1 of Unity 5.
The exported user scripts are actually .Net assemblies. They are run via the mono VM using it's JIT (just in time) compiler on platforms that support it, and are AOT (ahead of time) compiled on platforms that don't like iOS.
In the case of WebGL the .Net assemblies are processed by a tool to convert them to C++ and then compiled into javascript using emscripten.
