It is usually the case that message brokers like HornetQ are supposed to be used on the infrastructure side - i.e. running millions of messages between limited amount of subscribers.

I wouldn't say this was the usual case although it is a common use case. We have lots of users that have the opposite, lots of subscribers and few messages.

Is it a valid use case where HornetQ is directly accessible from users' devices (browsers, mobile devices etc) through STOMP/WebSocket servicing, say, 100 million connected clients?

How many connections a server can handle is ultimately controlled by what resources a server has, memory, disc space, OS file sockets etc etc. Which protocol you use will have no bearing on this, whether you use stomp,AMQP or the HornetQ core protocol.

Alternatively, is it still the case that a frontend is required (as usual) to "fan out" end-user connections whilst maintaining a couple of "real" MQ connections?

Im not really sure what you mean by this, how many connections there are and how they are used depends how you use the API, be it JMS, HornetQ or a Stomp client.