I have a similar use case. The current approach assumes that the LDAP server will be available at all times. If the LDAP server goes offline, and a user is created, they won't be synced (as far as I'm aware). I'm assuming this is primarily due to the issues around transferring the password information from keycloak to an LDAP server in a useful and consistent way. I think adding either an LDAP server, or at the very least a much better API for accessing user data would be a huge win for keycloak.
We've hacked around this problem by implementing a custom apache ds partition that uses the keycloak libraries to talk to our database. This is made more difficult by the way these libraries are structured. For example, at least as of 1.2.0, there is no way to query the database for a list of members of a particular role. This means that I have to build this mapping myself, then cache it so that I don't have to wait many seconds for every role lookup. Also, it's not an interface that is meant for public consumption, so it may change without warning, etc. The solution we have works, but certain operations are slow, and it may cause maintenance issues. I'm going to explore using the REST API instead, though it may not expose enough information.
Another potential issue is the IDs assigned to users/roles. Keycloak currently doesn't assign IDs that would be easily mapped onto the ID space that many systems would expect (32 bit int, or similar). I think this could be worked around, but it is another challenge for any universally useful LDAP directory backed by keycloak.