I don't see any fundamental issues with this from a patching point of view. The described process does not modify any existing modules or misc files in the distribution; it simply adds new modules. Users are free to do this, and application of a subsequent patch will not blindly disable those modules. A subsequent patch could have one of 3 effects with respect to those modules:
1) The patch doesn't include any modules with the same name and slot as one of these, nor does it include other modules with the same packages/classes. No problem. The x.y.z.mojarra-2.2.0-m05 modules will still be loadable.
2) The patch includes a newly added module with the same name and slot as one of these modules. This is extremely unlikely, given the slot names you are using. But if it did happen, the patch tool will regard the presence of the user-added module as a patch conflict and the user will have to include a param to the patch operation stating that the patch should be applied even though the patch will override a user-modified (in this case, added) module.
See Single Installation Patching for more on patch conflict detection and resolution.
3) The patch installs a new module with a different name/slot that contains jars with the same packages/classes. Now there will be two modules available that provide the same packages/classes. Which module gets used in a particular situation depends on the context. If the jsf integration somehow set up a situation where both javax.faces.api.mojarra-2.2.0-m05 and a javax.faces.api.main that contained different versions of the same classes were visible, that would probably be an issue (I haven't thought about it deeply) but that issue has nothing to do with patching. And I assume your impl was designed to deal with that.