First three rules of security: Layers, Layers, LAYERS.
To your point, in theory you could accomplish security by totally securing the JIT, or by totally securing the OS, and then exec's JITed code would be ok. However, totally secured JITers and OSs are as mythical as sufficiently smart compilers.
Totally secure, sure. Nothing nontrivial is totally secure, but...
One reasonable option would be requiring any JIT to be via a typed assembly language. You should be able to get a good compromise with close to the performance of native code and the security of verified bytecode from that.
Well, then you have to carefully vet every JITting assembly language. Microsoft in fact does this: the WinRT APIs run on .NET, which has an associated assembly language CIL (formerly MSIL) and JITting runtime, the CLR.
So, if you want a JIT via a typed assembly language you can compile down to CIL. Firefox could do this, but then they couldn't specialize their JIT to run JavaScript properly, which is the hard part anyways. V8 and Gecko are very cool engines, and compiling javascript to CIL wouldn't compete.
To your point, in theory you could accomplish security by totally securing the JIT, or by totally securing the OS, and then exec's JITed code would be ok. However, totally secured JITers and OSs are as mythical as sufficiently smart compilers.