It looks like we can transport with the API using Theme Update Endpoints and sharing environment API keys so one environment can see the next environment to copy the themes over.
Yes, that's what I'd recommend. You could have different API keys for each environment and have the script that promotes the theme pull the API key from a secrets store. Make sure you limit the API key to the themes endpoint.
But you can set variables in the Helpers template using assign that can be used in other templates. You could use a templating language like jinja to build the Helpers template at build time and then a script to load it during deploy. (Or even sed.)
You can also create different themes (a dev theme, a qa theme) and assign them via scripts to the different environments (unsure if you are using different tenants to represent environments or different FusionAuth instances, but the concept is the same).
You can put whatever you want in the theme pages, but it's a good idea to keep them lean so the user has a quick login experience. After all, most folks don't care about auth except when it doesn't work!
The issue is that the identityProviders map needs to be populated for that login script to work, and the class behind this page doesn't provide that map. So for now I don't see a way to do this.
There is an open github issue to allow identity providers to be displayed on the registration page. I'd suggest adding your use case to that issue: https://github.com/FusionAuth/fusionauth-issues/issues/554 and I'm happy to rename it to something more general. Alternatively you can file a new issue if you feel the use case is distinct enough.
In addition to what @maciej-wisniowski suggested, if you have a paid license you can now have application specific themes (one theme per application; if no application theme is specified, it defaults to the tenant).
You can see how that works in the sandbox environment (sandbox.fusionauth.io). I believe that feature landed in 1.27.0.