Well champ, so your goal here is to make sure you release your lock after its use, right? Well, you can achieve this goal with the classical synchronization or with a ReentrantLock, for instance. So it would be better to use what the Java language already provides natively. Knowing the API is also a scoring criteria. Also, using an implementation that is offered by the language is prefered over an own implementation that would do something similar. So I'd say that you are introducing an unnecessary complexity. My advice would be to keep things simple and use what the language already provides. Most of us that passed this certification achieved this goal without providing our own implementations!
I think it doesn't add any value. If you would create some kind of framework, it is important to make the developer (user of your framework) to do a lot behind the scenes (so the developer can focus on real business logic instead of boilerplate code). But now you just have 2 methods which need to be enclosed in a lock/unlock sequence, so in my opinion that's killing a mosquito with a hammer.
This stuff is just on top of the API, to make sure one doesn't forget to do the lock/try/finally/unlock. But then, in the end, it doesn't provide much, esp since there's no way I can force the developer to use it, and is quite some boilerplate code. So I'll just skip it. Sorry for the noise and thanks for your answers.