Using identities for that is actually somewhat problematic because identity theft is generally pretty easy. The attacker compromises many devices, or a database containing the information of millions of people necessary to impersonate any of them to the token issuer. Then not only does the attacker get a large number of tokens, a large number of people also lose the ability to sign up for the service themselves. It also opens you up to deanonymization attacks if the token issuer and the site collude, or anyone else can compromise or coerce both of them at once.
But there are plenty of other alternatives.
You could ration them based on some other scarce thing, e.g. issue only X number of tokens per public IPv4 address or IPv6 /64 block per year.
You could exchange tokens for a security deposit. A few dollars for a token that can be used for over a decade is a minimal cost to a real user, but a few dollars for a token that lasts 90 seconds before getting banned is a real cost to the spammer.
And you can combine them. One free token per public IPv4 address per month, and if you need more then provide a security deposit.
It might be possible to do something based on one of the centralized "digital cash" systems that cryptographers have developed. A typical system allows some central entity (e.g., a bank) to issue a "digital dollar".
The digital dollar can be transferred to a merchant in such a way that the merchant can turn it back in to the bank, and the bank (1) can recognize that it corresponds to one they issued, (2) can tell that it has not previously been turned in, and (3) gets no information whatsoever about who they originally issued it to.
So suppose some entity that people trusted revealing their identity to provided a service where you prove your identity to them, and they use a digital cash system to issue you a token. You can redeem that token at Twitter, which verifies it with the issuer, and if it is valid and not previously redeemed, lets you create an account with no further need for identification.
The token issuing entity does end up with a list of real identities of Twitter users, but has no way to match those to Twitter accounts. (Or rather, they have the identities of people who asked for Twitter account creation tokens...they have no way of knowing if a given person ever actually went ahead and created an account).
If your Twitter account gets banned and you want another one, you'll either have to try to go through the token issuer again, and they can see that a token was already issued using your real identity and refuse. You'll have to do something like get other people who don't have Twitter accounts to use their real identities to get tokens, and then give those to you.
That was just an off the cuff idea, to suggest some possibilities, and based on the capabilities of the earliest digital cash systems. I bet you could design a more sophisticated system where the token issuing entity works with multiple sites, and can't tell which site you are getting a token for, but can still limit you to one account per site.