This is self-defeating.
axiom: Convenience when coding is important.
Proof of axiom: If you didn't care that much about it, clearly writing 'setX' is no hardship compared to writing 'x', and therefore you can just go with POJO style and be happy. If POJO style alone is not good enough for you, then clearly you care about stylistic choices.
Given the above rule, then... how in the blazes can you accept the situation where you have BOTH 'name(String newName)' AND 'setName(String newName)', being equivalents of each other, in the same class? That's not nice style at all. And we've already posited that you care about style and APIs and such.
I guess it works out if you care about certain aspects of API design but don't care about others, but the kind of scenario where you get there just doesn't add up to a consistent programming experience in my view. Evidently this is a world where you write in notepad and the auto-complete dialogs of your IDEs are irrelevant. Lombok is not designed for you, if that's how you program.
The harsh penalty of seeing double in your API docs and all other places 'list of methods' comes up (such as your IDE's outlook views and autocomplete dialogs) is vastly more costly than the gain of being able to write fluent API whilst playing ball with stuff that expects beanspec style setters.
One utterly crazy trick solving both problems in one go is that we generate synthetic beanspec methods, thus conviently making it illegal to call them from java source and having them not show up anywhere relevant (not in javadoc, not in auto-complete dialogs, at any rate), and yet, at the VM level these methods exist; you can reflect into them and compiled code can call them just fine. It's javac / ecj that act as if synthetic methods do not exist, the VM doesn't look at the 'synthetic' flag.
The problem is, we can't make em synthetic without a post-compile class rewrite op, which means the feature is a bit complex, hard to explain, and the produced end result cannot be rewritten as a delomboked source file which is quite a big cost. We're willing to pay it, but not for such an exotic feature.