I'm afraid it will be quite tough, have a look to this thread in the Apple Developer Forums:
As far as I could understand, it seems that Apple's dropping support for MAC address spoofing...
Parallels supports it and it works just fine.
There is nothing wrong with Bridging to WiFi when using a Unique MAC Address from the VM/VNIC.
What's shown in the bug.png file in the original post is not a bug - it is the way link layer communication works, and that isn't interfering with DHCP. Instead of looking at the ethernet MAC address of the sender, you need to look at the Client MAC address in the DHCP Discover packet. That is most likely the correct MAC address of your client OS. If not, then something _very_ strange is happening.
VMware's bridge effectively puts the client and host on a separate network segment from the network segment the host is already connected to (the one with the DHCP server). This means that the client can't talk directly to the DHCP server without going through an intermediary device (the host in this case). The host relays the client's DHCP Discover to the DHCP server and since the host is the device that's actually transmitting onto that network segment, it _must_ use it's own MAC address at the link layer. The DHCP Discover packet will nevertheless contain the client MAC address, and the DHCP server will be able to respond with an appropriate DHCP Offer.
If the DHCP server is on a network where security is an issue, it would not be surprising if all DHCP Discover packets with a mismatch between the link layer MAC address and the Client MAC address are automatically discarded. This is done to protect against DHCP starvation attacks. Unfortunately, it also means that devices behind a bridge or a switch can't obtain IP addresses on these networks. If this is your situation, you might try talking to the network admin about registering the client MAC address as a valid MAC address, and having their security software check the Client MAC address for validity before tossing DHCP Discover packets with mismatched MAC addresses. FWIW this security issue is also the explanation offered by VMware employee nancyz in the alekappa thread. (Note that security measures would most likely result in no DHCP Offers being sent but bug.png clearly shows DHCP Offers, so security measures may not explain the original poster's problems.)
Please no flames - I'm not trying to say that there isn't a problem, nor am I claiming that security measures explain all the problematic behavior reported by various posters. This is just an effort to explain why the bug.png image in the original post does not indicate a problem, and to offer a little clarity about how the link layer works.