How is the SPI determined/negotiated in phase 2 of IKE (v1)?
Is the above description actually how it takes place?


No; it works as you suspect.  Each side chooses the SPI to use for the incoming SA; that is, how the other side marks encrypted packets that are encrypted with this SA; in the initial quickmode message, the initiator specifies the SPI that will be used for encrypted packets going to the initiator, in the response packet, the responder specifies the SPI that will be used for encrypted packets going to the responder.  This is done specifically so that, in either case, the decryptor can select SPI values that are convenient to look up; for example, it may chose to place an index into a 'decryption table' into the lower 16 bits, say (and yes, there are implementations that do that).


  If yes, what happens in case the responder receiving the SPI from the initiator finds out that the SPI value is already in use?


While (as above) the assumption behind this question is wrong, there is a nontrivial answer here, and so I'll answer that.

As above, the initiator selects its SPI first (that is, the SPI for its incoming packets), and the responder then selects its SPI.

Because of how IKEv1 derives keys, if the responder selects the same SPI as the initiator, the keys for the two SAs (going in the opposite directions) will be the same; depending on what transforms are negotiated, this can be disastrous.  I don't believe there's any requirements, but I know of at least one implementation that will, as a responder, always select a different SPI then the initiator, and as an initiator, if it sees the responder selected the same SPI, automatically close the connection without encrypting anything.