Yes, it is possible, but you lose the flexibility/efficiency part.
For example, say a user wants to log any output to a file. With String in the signature, you're forcing deserialization from UTF-8 to char[], then serialization again to the UTF-8 file (plus the GC overhead). With the raw pointer, you can do it with zero overhead.
Another issue is text encoding, which is not specified in the spec. I used UTF-8 here, which covers ASCII, but it could be anything I guess. With a String argument you're stuck with whatever LWJGL implements. With the raw pointer, you can use ASCII decoding for efficiency or anything else if UTF-8 happens to produce garbage. This is the reason why "unsafe" function versions are publicly exposed in LWJGL 3: if LWJGL does something stupid, in any API and any function, you can be sure that you will be able to implement a workaround without having to wait for LWJGL to fix it.
In any case, what I would like to do, after LWJGL 3.0 is released and if it turns out to be as stable as I hope it will be: a fork that will be maintained in parallel with the original library, but refactored for the latest official Java release. That means Java 8 now and it would make callbacks very friendly. There are a few things that could also be supported once Java 9 is out (e.g. VarHandles). By the time Java 10 is out, we could move the official library to Java 8 and the fork to Java 10/Project Panama.