Transmission of different messages with the SAME ID on a CAN bus
Section 6.1 of the CAN spec:


  BIT ERROR: A unit that is sending a bit on the bus also monitors the
  bus. A BIT ERROR has to  be detected at that bit time, when the bit
  value that is monitored is different from the  bit value that is sent.
  An exception is the sending of a ’recessive’ bit during the  stuffed
  bit stream of the ARBITRATION FIELD or during the ACK SLOT.


So, the node which first transmits a '1' when the other is transmitting a '0' will note a Bit Error and then signal an error as normal - by transmitting an error-flag (see Section 3.1.3) , as described formally in Section 6.2.

Informally, if that node is error-active (which should be the usual case) it will transmit an error flag of 6 dominant bits, which all other nodes will also detect (as a stuff error).  This has the effect of destroying that message completely: 


no-one will receive it
none of the transmitters will think they have successfully transmitted anything.


Each transmitter will then attempt to retransmit - depending on the precise timing of the retransmissions, one may start sufficiently before the other the gain control of the bus.  Otherwise, the same sequence may happen again.  (Or another higher-priority message may put them both off for a while!)



Extended answer inspired by @clabbacchio's answer below.

You mention "nasty nodes", and clabbacchio makes the valid point that if two nodes transmit at different times, each receiver needs to decide what to do with its multiple receptions.

This was demonstrated by a hack last year.  The paper discusses, in the section "PSCM specifics", how an attacker can synchronise to the regular messages on the bus and play their evil message just before the one that the "good" ECU is about to send.  The receiving ECU accepts the earlier message, updates its message counter and then discards the "good" messages as erroneous, because its message counter has not incremented.