Ich muss zugeben, dass mir erst bei genauerer Prüfung aufgefallen ist, dass das Passwortfeld für Benutzer, die E-Mail-Einladungen annehmen, optional ist. Du hast recht damit, dass Benutzer wählen können sollten, ob sie eine andere E-Mail-Adresse verwenden und ein Passwort erstellen möchten. Ich wäre viel zufriedener, wenn die Benutzeroberfläche deutlicher machen würde, dass das Passwort optional ist, insbesondere wenn die soziale Anmeldung auf der Website aktiviert ist. Mit der aktuellen Benutzeroberfläche müsste jemand wirklich nicht wollen, ein Passwort zu erstellen, um festzustellen, dass dies nicht zwingend erforderlich ist – meiner Meinung nach. Ich denke, ich sollte die Ärmel hochkrempeln und einen PR erstellen, um die UX zu verbessern 
Ich habe mir den Beispielcode angesehen, danke! Nur zur Info: Ich musste diesen Hack verwenden, um die entsprechenden API-Aufrufe durchzuführen: Using the API to create a user on an SSO only system - #13 by DylannCordel – selbst dann glaube ich nicht, dass dies den Anwendungsfall abdeckt, den ich im Sinn hatte, da dies eine E-Mail an den Benutzer zur Aktivierung auslöst. Ich hatte gehofft, dies zu vermeiden, um stattdessen eine nahtlose “funktioniert einfach”-Erfahrung zu haben, falls und wenn sie sich später auf der Website anmelden.
Ich habe auch ein wenig mit dieser Lösung herumgespielt: How to manually add user in discourse? - #10 – Ich denke, es würde funktionieren, Benutzerkonten, die ich habe, mit dieser Methode einzufügen, aber letztlich bin ich mir nicht sicher, ob es sich für mich lohnt, das Risiko einzugehen, die Umgebung direkt im Container zu modifizieren, um diese Änderungen vorzunehmen.
Also, alles in allem, denke ich, dass der Arbeitsablauf, den ich mir erhofft habe, nicht wirklich ein unterstützter/erwarteter Arbeitsablauf ist, und ich werde damit leben müssen, bis die Benutzeroberfläche (vielleicht) irgendwann verbessert wird.
Danke an alle!