I can't remember what tests I did at the time, but I've just had another look at this on a MacBook Pro running 10.8.5 and VMware 6.0.0 Professional with an Ubuntu Linux 12.04.2 LTS VM in bridged mode.
I'm connecting to an 802.1X based network (eduroam) and this time I can DHCP the VM and receive a different IP address to the host machine, so no address clash there (although the clash was what was reported to us at the time).
However, the VM fails to communicate with the network (I can't ping the gateway or otherwise communicate).
Looking at the DHCP request in the VM (using tcpdump at the Linux shell), the messages go out with the source MAC address of the packet being the virtual MAC of the VM and the client MAC address in the DHCP request itself being the same.
Looking at the DHCP request grabbed on the host (from Wireshark), they have a source MAC address being that of the burned-in address of the real wireless card but with the client MAC address of the VM in the DHCP request itself.
Our DHCP server will then happily give out a different IP address to the VM and the VM picks this up and configures it. However, it then gets no communication with the wireless network.
In the rest of the capture, all the traffic from the virtual machine is going out of the host adapter with the MAC address of the host machine.
Looking in the user-table on the Aruba controller, there is an entry for the host machine, when searching for it by username, MAC address or IP address.
However, there is no entry for the virtual machine, making me think it hadn't actually started a session for traffic to be allowed, which is why everything was being blocked.
I'm not sure if this has changed since I last looked, when running VMware 5.x, or if the capture from the host is incorrect somehow (I don't really see how the virtual machine can send out traffic with the host machine as the source MAC address as the host wouldn't know which traffic was destined for the VM vs the host, so I'm not sure if this test is correct.
However, having the source MAC address of frame being different from the client MAC address in the DHCP packet being different is certainly something that DHCP Snooping can reject (as it suggests things being spoofed). However, that the DHCP requests are getting through might suggest this isn't be blocked here but later one, when ARP and IP source addresses are being checked.
I'll do some more tests to see if I can get the duplicate IP address problem with VirtualBox...