Cool. Glad we got things going again!
I still felt there was too much mystery (and too little explanation) in the solution, though, so I dug a little bit deeper, and found something interesting...
On my Mountain Lion host (MacPro5,1, 10.8.2, with no 3rd-party drivers loaded), I have only eight free character device major numbers free immediately after the OS boots. This is very surprising – it's much lower than I'd expected. The dump of /dev you kindly provided shows that VirtualBox claims at least two of them (37=vboxdrv, 38=vboxnetctl), Viscosity VPN claims at least another two (39=tap*, 40=tun*), Intel HAXM claims at least one (18=HAX);. It's entirely possible for drivers to claim those numbers without appearing in the listing of /dev, so there may be others consumed besides the ones we can see.
VMware Fusion wants at least two (one for vmmon– a.k.a. vmx86– and one for vsock).
So... I think that it may not have been any one single driver that caused the problem... it was simply that there were too many "character drivers" on your host, and removing one of them freed up enough devices for Fusion to successfully launch. It would seem that we need to ask Apple to allow more of these character devices to be created...
Thanks for your patience with this issue. Not only did we successfully solve your immediate problem, but I learned a lot about how our driver integrates into Mac OS, and we've found another possible action we can take to help make Fusion more robust in the future. Awesome!
Cheers,
--
Darius