The plus symbol has a special meaning in most email servers. While it is part of the address, it generally doesn't affect who receives the message. So email@example.com goes to firstname.lastname@example.org. This is true for Gmail for Business as well.
Gmail's filters aren't as sophisticated as those in, say, procmail, or even, as far as I can tell, Outlook. But if you get email@example.com set up, all the messages for those pairs will go through there. But you can write a filter that searches, for example, for to:yourname and tag it with a special label.
Because of that, and because Google limits how many rules you can have that forward email, I'd probably just start by setting dev up as an alias or a mailing list, and make sure everyone gets those emails. Advise each team member to set up a filter that looks like "to:dev to:theirname" and capture it in a way that will get their attention (Apply a label, star it or whatever works for them).
If you need something more sophisticated than what Gmail offers, such as only forwarding the relevant messages to the right developer, you'll need firstname.lastname@example.org to be a real account. You can then use a tool like Sift, perhaps on a lightweight Amazon instance or on an underutilized machine sitting in a closet somewhere, to process the messages and forward them as needed.
Another alternative is to recognize that there are two fields of relevant information stored on each commit: the author and the committer. Author and Committer are automatically the same under typical circumstances where multiple people have commit rights. However, in workflows where one person pulls a change from someone else and commits it to the core repo, the author and committer may be different. You can force this to happen using either of two mechanisms, explained on A tour of Git:
If you specify a --author option to the “git commit” command on the
command line, followed by a "Real Name " string,
then this name and addresss will be used for the author fields. The
committer fields will still be determined as below. This option is
very helpful for when applying a commit originally authored by someone
other than yourself.
If any of the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME,
or GIT_COMMITER_EMAIL environment variables are set, then those values
will be used for the corresponding fields
If you have a file in your home directory called .gitconfig, with name
or email settings in the [user] section, then these values will be
used to set any remaining author and committer fields. For more
details on the contents of this file, refer to section 2.7.1 below.
If you have a file in the local repository called .git/config, again with
name or email settings in the [user] section, then these values will
be used to set any remaining author and committer fields.
If you have
set the EMAIL environment variable, this will be used to set author
and committer email addresses if still unset. git will query your
system to find out your real name from available GECOS field and your
username, hostname, and domain to construct an email address, (or at
least an identifier resembling an email address).
In a pairing context, which one is the author and which is the committer is an arbitrary decision, but the fact is that the distinction opens the door to documenting both people involved in any particular commit.
A reasonably savvy continuous integration or build system could leverage both fields to send notifications to two separate people, which I think would work nicely for pairing situations. I don't know whether yours would, having no direct experience with it, but it is probably worth an experiment or perhaps a dive into documentation to find out.