It's possible for two hosts to have the same MAC, due to spoofing, a mistake during manufacturing, or willful negligence on the part of the manufacturer. So,
1) In general, an Ethernet switch keeps a table of which MAC addresses are attached to which ports. It bases this table on the source address of frames it receives during the normal operation of the network. Upon receiving any frame, the source MAC is read and compared with the current switching table, and then added alongside whichever switchport it was received on.
So if there are two hosts, both with the same MAC address, then the switch will update it's MAC table every time it receives a frame from either host. The reachability of either host will flap on and off and be inconsistent.
2) Short answer: no. Duplicate MAC addresses will not trigger any sort of security problem in an unmanaged switch (a switch without configuration software), or a managed switch (like most Cisco/HP/Junipers) that has not been configured for port security. Managed switches will give you a warning printed in the console terminal if they detect a duplicate MAC (a MAC that 'exists' on multiple switchports), but by default they won't "do anything" about it AFAIK.
If you want to use port security options on a managed switch, you can do stuff like only allow 1 MAC address per switchport. The MAC address will be learned dynamically by the switch (like it usually learns MACs), but the difference is that once it is learned, it is bound to that switchport. Then, if the switch receives frames from a duplicate MAC on another switchport, it can place that port into a disabled state (shut it down.)
You mentioned deauthentication in your question. The port security feature of some switches is different that "deauthentication"-- it is deauthorization. They are similar but the difference is important; look up authentication vs. authorization.
3) Duplicate MACs will not cause collisions. Collisions are the result of a shared electrical bus. It is more of a race condition, although I haven't heard it referred to like that before. Remember, duplicate MACs are "allowed", as far as any out-of-the-box Ethernet switch is concerned-- they just cause a problem that will interrupt network connectivity to each host in question. The problem is a constantly changing switching table.
I had to "fix" the same situation in one of our production plants about 6 years ago.
I got to tell the production engineers that they were idiots :-).
In their defense: This was the first networking product ever and R&D hadn't exactly thought the production ramifications through.
There was no way around it then (and still isn't now).
Each device had to be hooked up individually to a PC to reconfigure the MAC.
(Later it turned out we needed to do this anyway because after some bugfixes had been done by R&D each device needed new firmware to be flashed as well.)
On later series the dev's made the process as painless as possible:
The standard firmware got a very basic minimal boot-loader that would boot a TCP/IP stack with a hardcoded fixed ip-address. This would startup and attempt to TFTP the full firmware image from another hardcoded ip-address. When done a second file containing the unique MAC would be pulled from the TFTP server and flashed in the device.
After that the device reboot, comes up with the full flash-image which does DHCP for it's ip-address. When the dhcp address is acquired it uploads a small file with it's own mac-addres to the TFTP server as confirmation that it is done.
The PC controlling this runs a DHCP server and a TFTP server. And a control application that prepares the file with the mac-address.
After the device has successfully uploaded it's confirmation file the control-application gives the operator the thumbs up to plug in the next device and it writes the next mac-address to the file.
(The application knows how long it normally takes to download and flash. It there is too much time between the first TFTP transfer and the upload of the confirmation file the operator is notified hat the device is probably faulty. Build-in quality test for the network stack.)
The Flash over LAN option is also a feature which the customer can use to upgrade firmware.
It had to be implemented anyway so we might as well use it to deal with the "how to get the initial config in there" issue.
PS. The DHCP server provides a custom DHCP option to identify itself to the device. In a customer LAN the DHCP will obviously NOT do that so when our devices see a "normal" DHCP server they just continue booting without attempting to upload the confirmation file.
Best Answer
A switch learns MAC addresses. Once it sees an address coming from a port, it will direct the traffic for this address only to this specific port.
In your case this means the two hosts will see only part of the traffic, depending which host sent the "latest" packet. The result will be very ugly networking problems. Do not expect the switch to handle this situation: MAC addresses are supposed to be worldwide unique.
A hub may work -- they simply spit out the packets on all ports except the one where it came in -- but these are very rare for 100MBit and non-existent for Gigabit. And of course half-duplex.