I have to admit I didn’t realize until close inspection that the password field is optional for users that accept email invites. You make a fair point that users should be able to choose if they want to use a different email and create a password. I would feel a lot better if the UI was clearer that the password is optional, especially when social login is enabled on the site. With the current UI someone would need to really not want to create a password in order to discover that this isn’t strictly required, in my opinion. I suppose I should roll up my sleeves and make a PR to improve the UX 
I took a look at the example code, thank you! For what it’s worth, I needed to use this hack to make the appropriate API calls: Using the API to create a user on an SSO only system - even still, I don’t think this meets the use case I had in mind because it triggers an email to the user for activation, which I had hoped to avoid in favor of a seemless “just works” experience if/when they eventually come to login to the site.
I also played around a bit with this solution: How to manually add user in discourse? - I think it would work out to hack in the user accounts that I want to exist using this method, but ultimately I’m not sure it’s worth the risk for me to be directly modifying the environment inside the container to make these modifications.
So, all in all, I think the workflow I was hoping for isn’t really a supported/expected workflow, and I’ll have to be ok with that until the UI gets improved (maybe) at some point.
Thanks all!