I have never tried this so my thoughts here are entirely speculation. Based on discussions I have seen in other posts, I suspect that doing a stop on the connection pool might remove the *-ds.xml file from the deploy directory. (I am not sure about that at all - there are up to a half-dozen MBeans generated for a *-ds.xml file and am am not sure what effect stopping one of them would have.) I suspect that once the datasource is stopped that your apps will get various errors. I do not know what will happen with threads that already have connections - most likely they will continue to use the connections successfully but then might get exceptions when closing the connection. You would probably have to do some recoding to gracefully handle these exceptions.
Now as I mentioned, this is all speculation. I could try this with one of my apps and report on what happens. But then, you could do that just as easily.
One other thought I had was to write your own datasource (or perhaps a service) as a layer over the actual datasource, and place into your datasource the ability to "temporarily shut down" the database. Then you could define the exact behavior for what happens during a shutdown and your apps will be depended on behavior that could change (which is a very likely possibility as you move to apps to newer versions of JBossAS.)
for example throwing a custom RuntimeException along the lines of a DataSourceTemporarilyUnavailableException. This could travel up the stack to the front-end and result in appropriate messages being generated for the system's users.
Why can't you guys handle this in through the application without playing with the JCa pool Mbeans?
You can have a utility class which will get the connection from the underlying datasource and if it fails to get the connection due to unavailability of DB this utility class throws required application exception.
Looks to me you wanted to take care of this scenario