First of all, inserting fake rows seems like the wrong way to me. I don't think notifications is that mature that one should avoid data model changes for any price by doing workarounds like this.
ad 1) I had this crazy idea: what about extending notifications so that the event generating code can optionally pass a sql query string to notifications, which will be executed by notifications at the time when it builds the recipient list (i guess/hope that list is built in the background already). The query would have to return a list of user_id's only, and notifications would join it against the subscribers list so that it results in the required subset. Just an idea - maybe it's nonsense. It would at least require some thinking how to make it multi-db capable (maybe pass the name of a qd query identifier plus values for the bind vars?).