I looked at the spec briefly (http://wiki.ecmascript.org/doku.php?id=strawman:value_object...), but it doesn't talk about the how.
I understand nan-boxing and similar techniques, but they seem to imply at least some runtime overhead to test the type of the value in some cases. Also, AFAIK, 64 bit integers cannot be represented with nan-boxing, as there are only 51 bits available for the payload.
There are already multiple types in JavaScript, and this already affects performance; for example "+" is defined for both numbers and strings. All JavaScript engines handle this in the same way, more or less. You start out with a "baseline JIT" that does not make assumptions about the types of objects and has type-check-and-dispatch on operations like "+". These type checks record the types of objects that have flowed through each point. Once enough types have flowed through so that we can reasonably predict the types, we recompile the function to assume that the same type (for example, number) goes through, which enables greater optimizations. You then hoist type guards up (or eliminate them if you can prove them never taken) so that you deoptimize and bail out.
Value objects don't change this overall picture, they just add more types.
All of this, however, is irrelevant to asm.js. With an ahead-of-time optimizing compiler, we know what the types are beforehand via the asm.js spec. So there are no type guards inserted at all, and none of this is an issue. For example, NaN-boxing is not used in the Firefox asm.js compiler (OdinMonkey). We know which values are doubles and which are integers, so we need no runtime guards or type tests at all.
On the other hand, Dart doesn't have required type annotations either and it has 64-bit ints, doesn't it? So it should be possible to introduce in JS.
Runtime overhead is likely, but then when you're in the JIT sweet spot the types are all known so you get JITcode that doesn't check types.
GC is a related example of a place where VM designers told us not to worry ourselves, but it turns out that GC is inherently hard and you are going to pay for that convenience - either in performance or in memory. See: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow....
This is precisely what "use asm" is for. It gives you direct control: each allowable operation in the subset has a direct analogue to the appropriate machine instruction(s). If you fall off the happy path and stray into "JIT magic" territory, you get a message in the developer console telling you to fix your code.
Unfortunately V8 is opposed to "use asm" in favor of the "JIT magic".
I agree that not having to rely on the JIT to figure out how to optimize your code with 'magic' is preferable. I tend to lean towards that where possible in most of the JIT/GC-based environments I use (C#, JavaScript, etc), and it tends to pay off.