I believe that the JNP implementation supports multiple URLs.  However, even if it doesn't you should still be able to consume all the messages in a queue in the cluster just by connecting to one node assuming that you've configured a non-zero redistribution-delay.

Also, the connection factory you client looks up via JNDI should be using the default round-robin connection load-balancing policy so when you use the same connection factory to create multiple connections those connections should be distributed across the nodes in the cluster in a round-robin fashion.

When all the messages of a queue in a cluster node are consumed but consumers are still attached then messages in that same queue from other nodes in the cluster which have no consumers will be redistributed to the node where the consumers are attached.

One thing to think about...If your load is so small that you're starving consumers then you may not need a cluster at all.  A single HornetQ node can handle millions of messages per second so it's quite possible you could use a single node and avoid all this extra configuration, testing, and management.  Have you actually conducted performance benchmarks which conclusively indicated that you needed more than one node?