MySQL no te permite generar un rechazo de inserción en un trigger. Un trigger se dispara ante un evento específico, sea antes o después de él, pero no permite cancelar la acción que lo disparó.
Además, tampoco se puede hacer operaciones DML como las indicas, en la misma tabla donde está el trigger en ejecución, porque la tabla está bloqueada.
Por lo demás, lo que quieres hacer es una validación en base, cuando lo que deberías hacer (y es lo que se hace) es una validación en la aplicación.
¿Qué sentido tiene enviarle a la base una inserción que antes de enviar se sabe que será rechazada?
En tu caso, pasa lo mismo que en este otro:
Duda procedimiento y la respuesta sigue siendo válida:
La aplicación es la que debe controlar que el usuario no pueda ingresar datos incorrectos y no la base de datos. Plantearlo al revés es un error conceptual y de procesos. ¿Para qué lanzar una consulta, que requiere tiempo de comunicación, procesador y lectura de disco, si sabes a priori que no podrá responderla porque no se cumplen con los requerimientos del modelo de negocio?.
Regla general de desarrollos con soporte de base de datos (aprendida en clase y luego probada por experiencia):
No se usa la base de datos para hacer validaciones. Las validaciones se hacen en la aplicación y de ser necesario, los datos que se piden a la base, pero no se valida en ella.
Nota: hay DBMS que te permiten alternativas ante un caso determinado, es decir, derivan el proceso a otra rutina o a otra acción, pero MySQL no lo hace. Como tampoco cuenta con constraints CHECK, no se puede aplicar ese concepto, por lo que mi recomendación es que programes más ortodoxamente: Valida en la aplicación.