It's supposed to be impossible. Each manufacturer gets its own MAC header, and the manufacturer is responsible for never generating the same MAC ID twice.
DHCP isn't responsible for IP to MAC resolution, so results may vary... theoretically, there would be no problem at the DHCP level. DHCP doesn't really even care about the MAC address; it's just concerned with host names.
The real problem is going to be your layer-1 equipment (switches) and ARP: this is the protocol that resolves IP addresses to MAC addresses.
If they're on the same Ethernet segment, this can cause all kinds of problems, depending on your network hardware. The problem is that Ethernet switches rely on the MAC address to know where to send packets. If you have 2 machines with the same MAC ID, the switch will get confused and only send packets to one machine. The most likely outcomes are that one computer will get all the traffic and the other will get none, or that the switch will sometimes send data to one PC and then to the other.
Also, ARP is going to get very confused. Depending on the situation, you could lock up routers as the two computers fight for the same hardware address.
There are situations where this works, however: this is actually a common practice on Windows servers, known as load balancing. Two servers assign the same MAC and IP address to their "public" network cards, and they share the traffic. However, there are some serious side effects from doing this: the computers require a second pair of network adapters to coordinate between them. They also have additional MAC addresses on the public ports for outbound traffic. Since the incoming MAC is never registered on the switch, all inbound packets are treated as broadcast packets and go to ALL comptuers on the subnet. (This is why you should put NLB computers on their own smart switch, connected directly to a router.)
When things go wrong with NLB, you get a situation where only one computer gets traffic, and the other one just sits there, deaf and dumb.
Update: longer explanation of DHCP vs ARP follows:
I said that DHCP doesn't care about MAC addresses; that's not entirely accurate: DHCP uses the MAC address to assign an IP address (and other parameters, such as DNS, routes, etc.) to the client, but it's not responsible for how other computers resolve IP's to MAC's. You can run a network with no DHCP server, and it will work just fine.
ARP is the protocol that lets other computers look up your MAC address based on your IP address. It's a decentralized process that uses a broadcast to ask "who has IP x.x.x.x?", and the owner of IP x.x.x.x responds with "That's me!"
If two computers had the same MAC and the same IP, they would both respond with the "that's me!" message at the same time. The receiving computer wouldn't know how to handle that: I believe the response to that situation is undefined, since it's never supposed to happen. My guess is that the first response would "win".
If two computers had two different IP's, but the same MAC, there are two possible outcomes: it's actually possible that they could, to a limited degree, communicate with other hosts on the same network, but only in a non-switched environment (for example, two hosts on the same WiFi router or an old Ethernet hub.)
In reality, though, network drivers check for address collisions and fail to start up when another computer responds to the "does anyone else have this MAC address?" question. Back in the ARCNet days, when you used 12 DIP switches to set the MAC, we used to have that happen sometimes. The network card drivers would fail when we made the mistake of setting a card to an address that was always in use.