I built a system like this for my former employer and is actually one of the reasons I started the work on Log4j 2. The system we used was based on events that were defined in a "catalog". From the catalog we generated interfaces that could be used to create logging events. These events were based on the RFC5424Message and were sent to the EventLogger. All events sent to the EventLogger were then passed to the FlumeAppender, which forwarded them on to one or more Flume remote agents. In those agents we then wrote the events to Cassandra and Solar (I believe they have since switched to using HBase). The point is, by routing all events from the various servers into Flume they can all then be easily routed to whatever the ultimate destination is, without having to reconfigure all the various applications.
That said, there is nothing wrong with using an ElasticSearchAppender if it is appropriate for your circumstances. I am sure we would be happy to add it to our group of NoSQL appenders.
Also, it is my hope to create the auditing/event catalog framework I described as a new Log4j subproject.