No. The Public Key is unknown for the vast majority of active addresses.
What is the PubKey or SHA-256 hash of the PubKey for this coinbas reward in this block:
https://blockchain.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26fHint: only the owner knows. If this output is spent in the future you would have no method of knowing if it was the "real" owner's spend or a pubkey collision.
Bitcoin INTENTIONALLY makes the PubKey UNKNOWN until an output is spent. Once it is spent there is nothing to "protect". Addresses shouldn't be reused.
So it is not a solution, even for this non-problem.
The supposed problem is someone creating two random private keys that spend the same address, because I am the creator of both, I know both, I think I understand what you want to say, but you don't understand me.
That isn't the (non) issue proposed. The issue the OP proposed is a hash collision.
Two PubKeys A & B such that the hash of A & B are the same.
Bitcoin standard tx are payments to the PubKeyHash. So if A & B have the same hash then the private key for A or B can be used to spend outputs sent to that PubKeyHash.
A MINER DOES NOT KNOW THE PUBKEYS AT THE TIME AN OUTPUT IS CREATED. Payments are only to the PubKeyHash.
The scenario created by the OP is a complete non-issue, however your solution isn't a solution either. How can miners record the pubkey or first round hash for a value they don't know. They won't know the PubKey (as opposed to the PubKeyHash) UNTIL the output has already been spent. It solves nothing. Once spent the PubKey IS recorded. It is part of the input in the tx and is part of the blockchain. Making another recording of it does nothing, it has already been spent.
You don't understand the issue at hand I suppose. OP's scheme will only work(i.e., creating a hash collision) by finding two private keys.
A birthday attack allows you to find two output values f(x1)=f(x2) for some random pairs of inputs of x1 and x2, it doesn't care what you function f is, whether it is some hash(x) or hash(ecc(x)) or hash(wtf(x)), as long as it's single input and single output it will work, so it's all the same 2^(n/2) attempts whether you try to find two privkeys with colliding hashes from their pubkeys, or just two pubkeys with colliding hashes.
However, in our particular case the simplest hash(x) scheme will not work because it requires an infeasible number of equality check and storage space, because the input pubkey length is twice as large as the output length so only the naive method applied, yet for Bitcoin the private key is 256 bits, the same length as the output, cycle detection
http://en.wikipedia.org/wiki/Cycle_detection can be applied to reduce the storage space to constant.
It's a solution because miners are supposed to record hashes for any unspent address that is reused, so they will already know the hashes of the pubkey if a second pubkey tries to spend the same address, and that's why I say
not completely spent.
) 
No idea what you are talking about now? I am going to give up for the night.
