In short: maybe, but it might not be the best idea.
I would advise against such functionality, even if it is possible, since it negates the fungibility of the tokens (i.e. one token is not worth the same as another), and dApps that are ERC20 compliant do not expect this.
Another solution would be to make three separate tokens; one for each of the classes.
You can attach a string to these different tokens in the
name field as per the ERC20 protocol, and use that to delineate class in your dApp.
To answer your question in a strict sense, I don't think extending an ERC20 token to include metadata like this would necessarily make it non-compliant.
But by the same token (brutal pun.) the ERC20 protocol does not provide a way to differentiate between tagged tokens, so you would have to build that functionality into your extension as well.
In other words, ERC20 would have to be extended to support this, and it would not be transparent to ERC20-compliant consumers (wallets, etc.) what the difference was between the tokens, even if your dApp knows.
Perhaps some future EIP will implement "tagged tokens", and dApps will evolve to support that standard, but for now it isn't this way.