1)gruppi e clienti:

CLIENTE->appartiene->GRUPPO->effettua->PRENOTAZIONE

in maiuscolo le entità, in minuscolo le relazioni...
un cliente che non apparteien ad un gruppo.. formerà un gruppo composto da lui stesso.

L'unica cosa che mi lascia perplesso è che gruppo sarebbe un'entità senza attributi.. e non ha molto senso credo? però non posso mettere l'id del gruppo nella tabella clienti, perchè nel tempo il cliente potrebbe appartenere a diversi gruppi...

forse potrei mettere l'id in prenotazione (idprenotazione, idcliente, idgruppo) visto che avrò un record per ogni cliente..
CLIENTE->effettua->PRENOTAZIONE

giusto? in quel modo sono in grado di fare select che prendano tutti i partecipanti ad un gruppo...
ma non so perchè.. non mi sento sicuro di sta cosa
CLIENTE->effettua->PRENOTAZIONE
la relazione "effettua" è "molti a uno" risolve intrinsecamente il problema dei gruppi, senza creare un'altra entità, che come hai notato non avrebbe attributi.

2)Soggiorno.
come vedete:
PRENOTAZIONE -> soggiorno -> STRUTTURA
???

Sulle strutture alberghiere non ho problemi, esattamente come dice Fayble: generalizzazione e relazione con servizi...
quindi soggiorno avrebbe: idprenotazione, idstruttura, numero di giorni.
Così come l'hai scritta sembra che "soggiorno" sia una relazione ma dato che deve prendersi l'attributo "numero di giorni" potresti renderla una entità. Infatti se passi al diagramma relazionale soggiorno diventerebbe una tabella.

3) spostamento
...
Che dite? secondo voi è meglio questa "finta"?
No Crea un'entità con città partenza, città arrivo e mezzo come chiave primaria e come ulteriore attributo il tempo e chiamala "SPOSTAMENTO", quindi
PRENOTAZIONE -> effettua -> SPOSTAMENTO
se vuoi puoi usare delle entità città e mezzo di trasporto e legare SPOSTAMENTO a queste
Evita le relazioni ternarie.

4) se PRENOTAZIONE è legata con due distinte relazioni a SOGGIORNO e SPOSTAMENTO