You're right; I obviously didn't think that through. It does seem like there ought to be a way to abstract out the design effort of working with ASM.js, but it probably wouldn't work with existing code bases.
Right now the best tool to target asm.js is a fork of Emscripten that compiles a program in LLVM bytecode to an asm.js module. So any language that targets LLVM should be relatively easy to compile to asm.js.
The issue is that asm.js doesn't provide the full JavaScript & DOM API. Calls to native JavaScript functions go through a foreign function interface. The natural design in this case is just as you describe: a self-contained core for high-performance calculations called by a shell of plain JavaScript that can interface with the rest of the world. Similar two-layer patterns are used for NaCl Chrome apps, or games using Lua to script a C++ engine.
My original comment was written in the hope that existing language-to-JavaScript compilers could be modified to target asm.js, automatically gaining its performance boost for all future and current projects using, say, GWT. But existing projects aren't written with the two-layer pattern needed to target asm.js effectively. Perhaps the best you could do would be to run every function call that isn't in the module or asm.js stdlib through the FFI. That may not be worthwhile.
(Anyone can feel free to correct me if I'm totally off on something. This isn't exactly my specialty.)
