よく見ないと気づかなかったのですが、メール招待を受け入れたユーザーにはパスワードフィールドが必須ではないことを認めます。ユーザーが別のメールアドレスを選択してパスワードを作成できるべきだというご指摘はもっともです。特にサイト内でソーシャルログインが有効になっている場合、パスワードが必須ではないことが UI でより明確に示されていれば、ずっと安心できると思います。現在の UI では、パスワードを作成したくないと強く思わない限り、これが必須ではないことに気づくのは難しいように思います。そろそろ袖をまくり上げて、UX を改善する PR を作成しようかなと思います 
サンプルコードを確認しました。ありがとうございます！参考までに、適切な API 呼び出しを行うためには、以下のハックが必要でした：Using the API to create a user on an SSO only system - #13 by DylannCordel - それでも、私が想定していたユースケースには合致していないと思います。なぜなら、これではユーザーへのアクティベーション用メールが送信されてしまうからです。私は、ユーザーが将来的にサイトにログインする際に、シームレスに「そのまま動作する」体験を提供したいと考えていたため、このメール送信は避けたいと思っていました。
また、こちらのソリューションも少し試してみました：How to manually add user in discourse? - #10 - この方法で存在させたいユーザーアカウントをハック的に追加すれば機能するとは思いますが、最終的には、コンテナ内の環境を直接変更してこれらの変更を加えるリスクを負う価値があるかどうかは確信が持てません。
というわけで、全体的に、私が期待していたワークフローは、実際にはサポートされていない、あるいは想定されていないワークフローのようです。UI がいつか（もしかしたら）改善されるまで、それで納得するしかありません。
皆様、ありがとうございました！