I'm replying to my own post, because I worked it out. I used to do Mac Driver development at Intel, and since the likely problem here was a kernel or driver issue, I thought I'd set up two-computer kernel debugging as described in the Kernel Debugging Kit. I figured I'd catch the verbose spew on lldb on the debug host computer and the last driver to try to load would be the culprit. The first step doing all that is to switch to a development kernel and invalidate the kext cache. I forgot to hold down Command-R to return to recovery mode after the kernel swap, and it continued to completion and I was able to log-in. I switched back to the stock kernel (after blowing away several cached versions created on the reboot and removing all my boot-args from nvram) and it all still worked. This is just a hypothesis, but swapping the development kernel and the shipping kernel in and out should have been a no-op, but instead it fixed the problem, so I think the answer is that the kext cache invalidate was the magic sauce. If you are very confident and reasonably well-acquainted with such techniques, and you find yourself with the same failure mode, I recommend following the setup instruction for debugging as set forth in the readme for the Kernel Debugging Kit (see developer downloads). You don't need to do the whole thing necessarily. I would try just turning off the System Integrity Protection, followed by just the call to kextcache -invalidate <volume>, all from recovery mode, then see if the reboot fixes your problem. Remember that in recovery mode, your main volume with the kernel and its cached versions looks something like "/Volumes/Macintosh HD" (and remember to quote the name or escape the space - as in /Volumes/Macintosh\ HD). Also, don't forget to turn SIP back on when you're sure everything is working. Worked for me.
