I'm just going to chime in here, it's been said enough, but vWii mode on the Wii-U is not emulation... There's nothing to 'emulate' as the instruction set for the CPU used on the Wii is fully supported by the Wii-U. Emulation is used when you have a dissimilar instruction set between the software you want to run, and the CPU it's being processed on. For example, the instruction set supported on an old NES is that of a 6502 (A slightly modified version of a 6502 but still basically a 6502), so when you use an emulator it's translating all of the assembly code instructions into a language that your CPU can recognize and process. Some / most instructions require multiple 'passes' to properly translate that code to something that the emulating hardware can understand and process. Think of this, if it only took 2-3 extra instructions to translate the code you would need a CPU that's 2-3 times as powerful as the hardware you're emulating. That's an EXTREMELY conservative estimate as translating instructions from a process specific ASIC to a general purpose CPU generally requires 5-10 iterations / cycles to translate most instructions.
Now back to the vWii and Wii-U topic and how the above information applies, the instruction set supported on the Wii hardware is FULLY supported within the vWii environment and requires no translation of the machine code being executed. If there WAS translation going on, then you would have a form of emulation happening to make the vWii work. Good hard evidence that there's no translation going on is that the CPU clock speed is reduced back down to exactly the same speed as the Wii, as well as the extra cores being disabled. This allows them the best chance of running Wii code exactly as it did on the Wii hardware, no clock speed differences to mess up some games that might have been 'optimized' for Wii hardware only. (Another way to say that is poorly coded, but that's a term that would have to be qualified by looking at the code for a game's engine)
I think the biggest qualifier of the word 'emulation' is being missed, that's translation. Changing the machine code language so that it could run on a different architecture on the fly. That's not happening here as the code is being run natively on the CPU. Hell, even virtualization is a stretch to me... To me it's more akin to having a dual boot linux system for example, one OS has the CPU running at full bore and all cores enabled while the other is using a kernel compiled without SMP support and a set CPU speed. Just because you pick an icon for it doesn't mean it can't set a flag on the system and then reboot using the alternate OS, to me that's not even virtualization.
That was a bit to type and probably TLDR; but maybe it will give a little insight into what's happening here and the classification of it.
FWIW I've been designing and reverse-engineering applications / OSes on embedded devices for about a decade and a half. Just wanted to state that I may not be a industry expert on it, this stuff is kinda right up my alley.