1. the CPU cannot determine anything of this sort in general, it'd be equivalent to solving the halting problem (cf. Rice's theorem). if you think otherwise i think the whole world would be dying to know how to pull off such a feat ;).
2. Secure Boot (and its key management in particular) was proposed here to solve the problem of not booting untrusted code, i.e., the entire trust was placed in these keys all the while ignoring the fact that the UEFI code is in the same 'trust domain'. i'm glad you actually agree with me that separating the two is non-sensical.
3. your statement about the NSA's capabilities requires justification. some food for thought: backdooring doesn't require source code (and especially not permanent source changes). backdooring doesn't require the cooperation of firmware producers (also the food chain is longer than that). backdooring can be targeted. etc.
4. the security of the firmware becomes relevant *exactly* when it comes to key management. how else would you know whether the firmware does as asked (removes the MS key for good) or just pretends to do so but still accepts some blob containing some secret magic signed by the supposedly revoked key? one more time: you *cannot* separate the trust in UEFI code from the trust in the keys it manages. so any 'improvement in security' based on removing the MS key is just a feeling at best, not actual security.
5. availability of some source code on the net has exactly zero relevance to the code running as your machine's UEFI firmware. you can audit it all you want, it won't give you all the backdoors that could exist in the actual binary stored in flash (and to be honest, it'd be rather dumb to risk exposing anything of this sort in this kind of source code anyway).