I’m assuming that you would either hack the CM’s code or write your CM, and:
Maintain the part of the CM where it connects to the XMPP server
Add a processing module for your device
Modify/replace the part that let clients to connect to, so that your device can connect to the CM, and each of your device will become an XMPP client.
Yes, it is indeed possible. You can read about the CM’s JEP in Connection Manager JEP.
However, I’m wondering if you would consider another approach altogether. If I were given the project I’d proceed as follows:
The processing module can run in an Openfire plugin. I would use Botz: Internal Bot Library for Openfire and create an internal bot to emulate an XMPP connection for each of my devices. I’d extend the BotzConnection class to support bots multiplexing, and let all bots use a single BotzPacketReceiver object for central processing job. The packet handling and processing job is all done in a single plugin. So what kind of interface will there be between the devices and the plugin? I have a myriad of selections because I’m not limited by any protocol. It could be a database transaction table, a web service, or whatever I think possible.
An advantage of doing this way is that you have full access to Openfire API. Whereas, a CM restrict your capabilities only to those features available between a normal client and a server, and dictates your clients to follow the protocol in xmlns=‘jabber:client’ namespace.
The disadvantage of doing this way is that you add up a processing load to Openfire and limit your ability to scale the system. However, a good system design would anticipate the future expansion and support for clustering; thus, overcome the limitations. The clustering support is available in Openfire Enterprise.