Apple Pay: An in-depth look at what's behind the secure payment system

You mean exactly like the EMV that is on every Canadian credit card since about 2007? NFC / Chip hold unique tokens that have on device cryptography, exactly as you've described. You can't "steal" anything of consequence via NFC or the chip, and that's why it was designed. Further while you say that it's for the vendor, the liable party for fraud is actually the credit card companies, which is exactly why they made EMV.

You seem to think this is all new because of EMVCo, however it is a standardization for the last mile: Google Wallet originally was doing what the credit cards themselves do, holding the secret key and identifiers on an NXP secure element. There are issues with that (largely carrier related) which is why the industry started moving to software-held tokens, as in the Apple solution. Presenting an iPhone token offers zero additional security over presenting a Canadian chip or NFC credit card, and that notion is rather ridiculous.

(I'll address the rest later)

Somebody sees the credit card number, even in token based systems, even if it's only for a moment to acquire a token.

In other words, either Apple stills sees it while it acquires a payment token, or someone does to issue the payment token, as it's the only mechanism that identifies the account number to get a token for. The tokenization specification has a whole section on what identification and verification should be taking place to ensure the "primary account number" (credit card number) that the payment token is replacing is one the user has authorization for.

So let's focus on the "stores and charges". Yes, Google stores and charges your primary account number. This is just because Google happens to be the one doing the payment processing. Even in a token based system, again, somebody on the other side knows what real primary account number (credit card number) this token links back up to so they know what to subtract money from. The token based stuff is not an full anonymization protocol, it's mainly a way to securely avoid transmitting and storing credit card info to/by random merchants. In that respect, the virtual credit card numbers provide the same protection. They are one time use, and interception or storage by the merchant can not harm you. Secondarily, the payment tokens are also a way to reduce the number of networks your credit card number goes over, when used properly. The virtual credit card numbers perform the same function here too.

The person who knows in either system is usually your payment processor (though in case it isn't, it's possible for the tokens to be used there too. however, nothing in Apple Pay currently guarantees this happens with the tokens). Since that is google here, it makes sense they would have the primary account data to do the lookup.

If you are expecting tokens to replace credit card numbers all the way to the issuing bank, you are sorely mistaken. The lookup happens much earlier than that.

The TL;DR is that virtual credit card numbers are in fact, a method of tokenization. The only reason they went with "token" is because they don't have to be credit card numbers, and because not all virtual credit card implementations have the same guarantees.

In any case, if you want fully tokenized systems, those have existed too, just not en masse.