Nope. We have no way of knowing how to test a connection, since what is bound may not be a jdbc DataSource. For instance, the jms adapter is deployed using the same code.
Even trying to find and call a getConnection() method by reflection will not always work even for DataSources since one option is to require the user to provide a username and pw.
I have to admit, im not a huge fan of placing datasource configurations in the deploy directory, where the ear's are sposed to go. Perhaps in future versions seperate directories in the conf dir (database/jms/other jndi deployed elements) would work better and allow for deployed elements to be tested on startup. Just a suggestion...
You are free to write an mbean that knows what kind of connection to expect and test it. I've thought of writing an "try this sql on this DataSource" mbean for this purpose, but haven't really felt a strong need. This issue has nothing to do with where the deployments are located.
I'd suggest you put the configuration for your app-specific datasource in your .ear, so you have one-package deployment of your app. You use the jboss-specific jboss-app.xml deployment descriptor.
You can set up as many deploy directories as you want by configuring the deployment scanner.
We pretty much regard jboss as a container for mbean components that can be assembled into enterprise distributed applications. Some of the components can be j2ee components such as ejbs and servlets packaged according to the j2ee spec requirements, but this is only one way of using jboss (even if the most popular at the moment).