I can understand wanting to potentially extend GSNRecipientSignature to add an admin role that could set the current trusted signer.
I was curious to understand why you might need multiple trusted signers?
GSNRecipientSignature I think was intended to be a simple use case to start users out. You can certainly create your own bouncer based on this and implement the kind of logic you are talking about! Feel free to share your results here, a more robust system of managing signatures would surely be welcome.
My understanding of your use case is that addresses who can mint tokens should be also able to use the GSN.
If you are creating a new token, then you could create a Custom strategy to check in acceptRelayedCall if the from address had the minterRole and if so approve the relayed call, otherwise reject.
If you are creating a contract that has the minter role for your token, then you could add a WhitelistedRole and check that addresses were whitelisted to call the mint functionality and also in acceptRelayedCall to check the from address was whitelisted.
GSNRecipientSignature uses an off-chain service signing (using a single trusted signer) the relayed call parameters of the users making calls via the GSN to the recipient contract. In your case this would result in an off-chain check that addresses were whitelisted to use the GSN and an on-chain check that addresses were allowed to mint.
As an aside, assuming that the users who can mint are using MetaMask, then you can create a dapp that uses MetaMask for addresses to sign a relayed call: