NES -> native executables: http://andrewkelley.me/post/jamulator.html
x86/Windows starcraft -> arm/Linux for openpandora: https://pyra-handheld.com/boards/threads/starcraft.73844/
(Tools used for this: https://github.com/notaz/ia32rtools)
For a lot of consoles, particularly older ones, this tends to yield worse performance than a JIT. Between different memory layouts, weird threaded code, jump tables, (and especially) self modifying code, a JIT can do a much better job building efficient code since it has all of the runtime information.
For newer consoles which more closely resemble PC hardware, things are definitely better; the current generation will basically look like the Starcraft port; an API compatibility layer.
https://en.m.wikipedia.org/wiki/Profile-guided_optimization
In other words, you create a JIT to run the executable, building a profile of the execution paths at runtime, and use that profile to guide a static decompilation process. That way it should be easier to identify the sections of self-modifying code, as well as model the behaviour of this code.
The only difficulty I can see is how much time it might take to map out all the code paths, but in principal it's possible, and there may be some efficient approaches for doing so.