There are more solutions which are better
For new applications which make use of native code instead of html, js, .net, etc... it will be possible to use app packaging (AppX), possibly similar to Mac bundles to distribute binaries that are compiled for multiple platforms. But this is not an issue for existing applications which is the reason for the original posting in the first place.
Software emulation that you mention isn't as silly as you'd make it out to be. Unlike the Mac Rosetta Stone project which effectively added an entire PPC subsystem to the operating system with optimized thunks in places where performance mattered full system emulation will be needed to make this work. Of course, you could use Wine and optimize the thunks as well, the problem is at that point that Wine isn't really that good.
Full system emulation will be necessary. By using something like QEmu as the core which has an really nice an speedy x86/x64 emulator or suffering the horrible performance of Bochs, it'll be easy enough to launch a full PC implementation. Most often, full system emulation is used for things like DolphinEmu which lets Wii and GameCube games function on PC. Those systems are a nightmare because long string instructions can't be optimized or even vectorized because data most likely is stored in files (that might be memory mapped) as big endian data which then needs to be converted to little endian on a PC for each individual load and store instruction. There are no nifty SSE instructions for byte swapping that can be used effectively for this. ARM however typically runs in little endian mode and that's the #1 reason why performance of ARM emulators on PCs are so good.
Endian swapping performance is generally the biggest problem with implementing full system emulators. ARM on the other hand is a close enough match to the x86 processor that long instruction chains can be optimized and even auto vectorized for NEON by a proper dynamic recompiler. It might even be possible that when executing new code chains for the first time, the compiled code and be instrumented for metric measurements and longer chains of code could be traced. This type of tech could make it so that in many cases, the code natively written for x86 might even run faster in some cases on ARM than on the native x86 core (clock per clock). Of course, then using the same dynamic recompiler on x86 to compile x86 to x86 might be faster. This is why modern development tools often offer an option called profile guided optimization.
I wouldn't suggest trying to run things like x86 builds of Handbrake (which makes use of x264, possibly the most optimized x86 code currently in wide use) through a full system emulator. The performance decrease would most likely justify the wait for a new build native to ARM. Though given the insane dependence of x264 and ffmpeg on GNUish compilers, it could be a relatively long wait before there's a decent ARM compatible GCC for Windows and corresponding mingw tools.
Now, one the system is emulated, using x86 applications from the desktop for a normal user would be no different than how you use XP virtual machine apps via Virtual PC for Windows 7. The virtual machine is started in the background, running an x86 build of Windows 7 or Windows 8 for example, then using RemoteApp, the ARM Windows desktop becomes the destination for the application. Then icons on the desktop can be created which would start the x86 apps by sending a message to the virtual machine (starting it first if need be) similar to how you can use SEXEC with X Windows tunneling on Linux to execute an application on another system by view it locally.
None of this technology is particularly difficult and for the most part, the concept would be to permit general user apps to run, not high performance ones. It should be good enough for most everything. And with a bit extra work, it might even be possible that code that is accelerated through GPU computing via Cude, OpenCL, or even just fragment shaders can run just fine as well. The x86 app's hooks for sharing buffers would just need to adjust memory locations to compensate for the second emulated MMU. An even bigger performance increase could be to merge the MMU code between the two systems as the ARM MMU and x86 MMUs are similar enough the Windows virtual memory subsystem calls for allocation can be pushed directly from one system to the other.
This is just one possibility, I could probably do all this one my one as it's a pretty easy thing to do. But I'll wait a few more weeks until someone else does it.
The biggest reason this came up more than likely is that x86, even in software form generally requires an x86 license from Intel to collect money for. Microsoft should have no problem getting one, but I doubt they value it that much. I'm not 100% sure, but I believe the x86 emulator on Alpha was made by DEC and the x86 emulator on Itanium was made by Intel. Microsoft might not even have an x86 license, otherwise, they could theoretically have just bought transmeta way back when.