Group membership with unique anonymous claims Is it possible to accomplish the following scheme?

There is a Server (S) and many clients.

Each client enrolls with S, exposing its real identity; S saves the real identity information in its database and executes some keys/identifiers exchange with each client (could be something like DHE or RSA). 

Then, someone sends to S a claim such that S would be able to tell that this claim comes from one of the enrolled clients, but not being able to identify from which one (inability similar to factoring large prime numbers). At the same time S should be able to save it and only accept 2 more claims from the remaining clients (i.e. the client that have sent a claim can't send it again).

No client should have such information that, if leaked, could invalidate the entire scheme. In other words, any exposure of the identifier of a single client should only put in danger the ability of this client to make its claim.

A case: 3 clients (X, Y and Z) enroll with S.
X makes a claim to S.
S verifies that it comes from one of the clients and saves it, notifying the client that the claim was accepted. S does NOT know that the claim came from X. At this point, S only knows that 2 of the 3 claims remain.
Z makes its claim. S verifies and accepts it.
At this point S knows that only 1 claim remains.
X sends its claim again. S finds that it was already claimed and rejects it.
Y sends it claim. S verifies and accepts it.
At this point, S knows that all the claims were made.
A paper was published in 2015 describing a scheme called Anonize to do just that.

It appears to be constructed around a specially designed Non-Interactive Zero-Knowledge Proof of Knowledge (NIZKPoK) protocol used by clients. 

First, a registration is made, whereby a client sends a commitment to a seed of a pseudo-random function. Sent back to it by the Server is the Server's signature on that commitment and the client's id, which becomes that client's master token. Then the client uses the seed to generate a single-use token. Finally, to submit a response the client has to prove by NIZK that it knows some master token, a survey conductor's signature authorizing some client to go through the survey, and that it indeed computed the single-use token by the seed it knows.

It's notable that the scheme actually makes it possible to conduct multiple ad-hoc surveys on a single server, without giving the server's operator an opportunity to track clients across multiple surveys. That is achieved by using a survey id, which is different for every survey, to generate single use tokens. A client can, on the other hand, only generate one single-use token for each survey id, which means it will only be able to submit one answer.

A usable online implementation can be found here and the development reference implementation is hosted over here.