No. WebSphere MQ follows the classic authorization model in which all access requests must resolve to a specific user ID. The permissions are granted on groups. The model is that an resource owner (the MQ admin in this case) grants group access to a resource and an account administrator enrolls users into groups. Not all shops require the separation of duties that this enables but in many cases it is mandatory.
In the case of the channels, the BLOCKUSER rules execute at a point in time before the OAM is called. The rules evaluate strings provided by a connection request, another CHLAUTH rule or the channel's MCAUSER. In order to evaluate a group, the channelw ould need to make OS calls MUCH earlier than it currently does. That would impact performance on channel start as well as make the channel code a lot more heavyweight and complex.
When I've had this requirement on consulting engagements I set up automation that compared the group membership to the BLOCKUSER list and any discrepancies reported. In one case the automation was set up to add new group entries to the BLOCKUSER list without human intervention but any deletions were referred to the administrator. This provides equivalent functionality but shifts the complexity and overhead to a script external to the channel code. The channels remain fast and performant while the group membership is reflected in the BLOCKUSER rule.