Alright, so we have investigated the issue. Here is the scoop:
The universal builds (the ones that run on all Macs) of Mac OS 10.6 and 10.6.1 will only boot if the CPU family is 6, and the CPU model is greater or equal to 13.
The universal builds (the ones that run on all Macs) of Mac OS 10.6.2 and 10.6.3 further restrict the check, and will only boot if the CPU family is 7, and the CPU model is one of 13, 14, 15, 23, 26, 30, 31, 46.
On a host with a Core i7 processor, as well as in a virtual machine running on such a host, the CPU family is 6, and the CPU model is 37.
Conclusion: The universal Mac OS 10.6.3 cannot run, either as a host (see http://discussions.apple.com/thread.jspa?messageID=11430561 ) or as a guest, in a physical Mac equipped with a Core i7 processor.
We believe that it is the reason Apple did a special "hardware" re-release of Mac OS 10.6.3: they created a new build 10d2063a (see http://support.apple.com/kb/ht1159 ) that
1) loosens the CPU identification code, and
2) probably fixes other Core i7-related things (like CPU idling and the likes).
Now Mac OS 10.6 and 10.6.1 appear to work in a VM on a Core i7 processor (because the CPU identification code is looser, so there is no need for #1 above), but i wouldn't bet the farm on that: I'm sure other fixes (#2 above) are needed for these versions to work well in VMs as well.
So to conclude:
o Short-term untested workaround: use Mac OS 10.6 or 10.6.1 in a VM when running on a host with a Core i7 processor, and do not upgrade the guest OS. Alternatively, tweak the virtual CPU ID masks, to force a 10.62 or 10.6.3 guest to see a virtual CPU model that it accepts to boot on.
o Long-term reliable solution: wait until Apple releases a universal build of Mac OS 10.6.4, and install that in a VM.
