But, you'd need a complete implementation of the OSX kernel and library API surface, because that's what an OSX app expects. If you're going to try to re-use the host kernel via a virtualCPU backdoor, you're not really virtualizing anything anymore and could just stick with the unix process model?

Not exactly, because using a separate CPU with a shared kernel can very effectively isolate processes from each other which is not possible with the unix process model. It would take either a serious kernel bug or a bug in the CPU hardware/microcode to cross the barrier in case of an exploit e.g. in a browser.

I'd rather see the sandbox model for process isolation improved, instead of trying to re-invent it from scratch with a virtual CPU that has backdoor traps for calling into the original kernel for almost everything. I'd think the attack surface would be about the same for that, and any kind of virtualization that is so lightweight that it reuses most of the host kernel. That's exactly the problem that the x86/x86_64 memory protection and CPU ring levels were intended to solve! :) Plus you won't have the stress of having to virtualize a separate network card, file system and memory map.

I encourage both of you to check out picoprocesses: http://research.microsoft.com/en-us/projects/drawbridge/