Not terribly easily, unfortunately. Your best bet is to send out explicit instructions about how to set email preferences so that emails about those events are not generated. You could update their preferences for them, I suppose.
You could implement what you want in the code a few ways. For instance, you could add logic to process_bug.cgi not to generate email for those events.
We added in our very old Bugzilla a checkbox in template/en/default/list/edit-multiple.html.tmpl that allowed "quiet" changes that didn't generate email until the next time the bug is modified. New bug email sends out everything that changed since lastdiffed, so by not updating lastdiffed, the change will eventually go out.
However, I would like to convince you to do none of these! I am reluctant to use the quiet change checkbox we have added because it means that I am substituting my judgment for that of each possible recipient. I guess this is OK for milestones and such, but in general, I want to respect each user's preferences.
If you decide to implement some changes in code or templates, you should visit #mozwebtools on irc.mozilla.org to talk about them, see if there are related bugs that have candidate patches, etc.
Another we do that's not in Mozilla's version is that we add headers to each outgoing email that makes it easy to filter out emails that people don't want.
There's a little bit of light at the end of the tunnel, though. I know that both Max Kanat-Alexander (and others who are mainline contributors) and we are giving thought to how to consider a bunch of changes to many bugs as one change "set." When that is implemented, it becomes more feasible to combine "change several bugs at once" into exactly one email per recipient.