Devo ammettere che non mi ero reso conto, solo dopo un’attenta analisi, che il campo password è opzionale per gli utenti che accettano inviti via email. Hai ragione nel sostenere che gli utenti dovrebbero poter scegliere se utilizzare un indirizzo email diverso e creare una password. Mi sentirei molto più tranquillo se l’interfaccia utente rendesse più chiaro che la password è opzionale, specialmente quando il login tramite social è abilitato sul sito. Con l’interfaccia attuale, qualcuno dovrebbe proprio non voler creare una password per scoprire che non è strettamente obbligatoria, a mio parere. Suppongo che dovrei mettermi al lavoro e creare una PR per migliorare l’esperienza utente 
Ho dato un’occhiata al codice di esempio, grazie! Per quanto riguarda il mio caso, ho dovuto ricorrere a questo workaround per effettuare le chiamate API appropriate: Using the API to create a user on an SSO only system - #13 by DylannCordel - anche così, non credo che questo soddisfi il caso d’uso che avevo in mente, poiché attiva un’email di attivazione per l’utente, cosa che speravo di evitare per offrire un’esperienza “funziona subito” e senza interruzioni, qualora l’utente decidesse in futuro di accedere al sito.
Ho anche sperimentato un po’ con questa soluzione: How to manually add user in discourse? - #10 - penso che potrebbe funzionare per inserire manualmente gli account utente che desidero, ma alla fine non sono sicuro che valga la pena rischiare di modificare direttamente l’ambiente all’interno del container per apportare queste modifiche.
Quindi, tutto sommato, penso che il flusso di lavoro che speravo non sia effettivamente supportato o previsto, e dovrò accontentarmi di questa situazione fino a quando l’interfaccia utente non verrà migliorata (forse) in un secondo momento.
Grazie a tutti!