Sure, you could attempt to mess around with the people trying to get into your systems, but there are a number of issues with this approach.
First of all, there is the risk that you'll catch legitimate customers/users who are trying to access your project. This could happen for a number of reasons, such as a banned IP address getting reassigned, the attacker using a public computer/VPN/spoofing their IP address, or a whole host of other reasons. It's worth pointing out the fact that a legitimate user won't be happy about being banned either, but as long as it is clear why they seem to be banned (such as by providing an error message), they're more likely to be accepting of it. If you lower the quality of your project by making it seem buggy, a user isn't going figure out the real reason that they getting these bugs, they'll think "this is a low quality project and I don't want to use it". Blocking them with an error message will help them understand what's gone wrong, but introducing subtle bugs that ruin the experience will make sure that they leave with a low opinion of your project. Banning them is the lesser of two evils.
The second problem is that you're poking the bear. At the moment, these attackers may simply be trying to see if they can break into a project for the fun of it, or to cause a bit of mischief (I will make a point that this doesn't make it OK, but it's certainly better than if they were attempting to disrupt service, steal passwords etc.). If they find out that you're attempting to retaliate against them, I'd posit that they would be much more willing to attempt to cause more costly damage. Retaliating isn't likely to make them stop, but it is likely to make them annoyed. It's worth mentioning that this point is making the assumption that the attackers aren't attempting to cause real damage from the offset. It's worth taking this with a grain of salt depending on your actual situation.
Thirdly, writing and testing the code that performs these actions (randomly deleting portions of their search field for example) takes time and effort that I'm sure could be much better spent either trying to prevent the problem or generally improving the project. You didn't specify whether this is a personal project or if it is for a business, but in either case I wouldn't be comfortable spending time on something unlikely to give you any kind of benefit.
In regards to other options available to you to help prevent this issue, I would recommend one of the following (dependent on what kind of project it is of course):
- Require an account (either from the outset or only for blocked IP addresses, similar to how Wikipedia does it)
- Temporarily block IP addresses
- Add more security to the backend
All in all, retaliating may make you feel better for a short while as you feel like you're "getting them back", but I would say that the negatives easily outweigh the positives in this situation.