In follow-up to this, it turned out that the devices in question were actually provisioned. I don't know for sure if this was the only cause of the issue, but after some messing around, I got the device to provision again.
Because the operating system's hostname actually matched the AMT hostname on one of the systems, I was able to take advantage of the unprovisionex.exe utility to remotely connect to, and fully unprovision the device. I was actually at home, and VPN'd into the office while doing this, which shows how, in certain scenarios, you don't even have to be physically present to resolve issues with vPro systems.
After I did a full unprovision with unprovisionex.exe, I was able to reprovision the vPro device without any issues.
FYI, the AMT Status/State showed as "Detected" in my Configuration Manager collection during this issue.