The second part is the challenge, and for some devices I've been unable to embed my own CA. I was hoping there was a proxy trick or some magic sauce I was missing. Perhaps where DHCP could automatically configure clients with a (insecure) proxy or something along those lines?
Nope, you're not missing anything.
I'm working on a similar problem (https://github.com/elahd/esp2ino/issues/16) with a project I maintain to sideload IoT device firmware (https://github.com/elahd/esp2ino).
I've been using both mitmproxy and IOXY (https://github.com/NVISOsecurity/IOXY), an intercepting proxy made specifically for MQTT. IOXY is a small, less mature project, but it's definitely worth checking out as a compliment to mitmproxy. Many devices managed via AWS IoT phone home over MQTT and, my limited experience aside, it looks like many don't bother validating certificates when authenticating over this protocol.
1. Getting the IoT traffic to your proxy machine. As you say this is fairly trivial when you can set a proxy, but a bit tricky otherwise as you need to run mitmproxy in transparent mode (https://docs.mitmproxy.org/stable/concepts-modes/). With some luck you can set a custom gateway on your device which simplifies the setup, otherwise you need to have the capability to set iptables rules on the router. I personally have a small $20 OpenWRT router dedicated for that. Alternatively you can run your own DNS server and point everything to mitmproxy. v7 now also supports SNI/host-header based proxying! The good news is that this setup is the same for all your devices and once it works, it works.
2. Getting the device to trust your (personal) mitmproxy CA cert. This one really depends on the particular IoT device and may involve some serious reverse-engineering if you are unlucky. I wish there would be a more of a "I should be able to inspect my own traffic" movement, but it's a tricky problem to solve.