O que exatamente você espera?
Neste caso, o objeto será instanciado pelo databind, aquele atributo estará vazio, e haverá um erro marcado no objeto.
Você pode retornar um erro para o usuário exigindo que se preencha aquele campo, ou pode preencher no servidor antes de salvar.

Agora, se esse bypass que você procura for uma forma de salvar ignorando a validação, não tem como, afinal os constraints servem justamente para impedir que determinado estados sejam persistidos

Opa,  intão brother, blz? 
É o seiguinte, esse é um sistema antigo, q eu não posso mexer nas tabelas. Imagina que eu tenho uma classe empresa, nessa classe empresa tem o usuário que inclui a empresa. Essa informação eu preencho no controller depois do submit. O problema, me parece ( me corrija se eu tiver errado...) é q o databind rola antes do começo da execução da action do controller. Então não importa aonde eu preencha essa informação que o hasError sempre vai retornar true. Sacou? Eu queria uma maneira elegante de contornar isso. 

Você não precisa se preocupar com isso.
Veja bem:
Na hora de chamar a action no controller, o grails realizará o bind e irá instanciar o objeto Empresa.
Você está correto quando diz que este objeto de cara estará marcado com um erro, mas isso impede o controller de seguir o seu fluxo normal. No caso, você pode setar a propriedade que está faltando e chamar o método save() e irá salvar normalmente.

Então, dentro do hasError  rola um return, que aborta o método. Eu queria ou não entrar no hasError pra validation error de databind ou não dar return dentro do hasError, sacou? Em outro caso de uso eu tirei o hasError. Mas queria saber se tem algum jeito mais elgante! Obrigado mesmo pela ajuda....

O Grails não vai automaticamente abortar uma action por que um objeto criado via data bind tem um erro de validação.
Poderia postar o código da action para olharmos?

Funciona mais ou menos assim:
class EmpresaController {
    def save(Empresa empresa) {
       // Aqui no inicio do método o objeto empresa já terá erros de validação, mas isso não impede a action de executar

        empresa.usuario = ..............
        if (!empresa.save()) {
            // Aqui vamos adotar um fluxo diferente caso haja um erro de validação, mas isso é feito explicitamente pelo programador
            render view: 'edit', model: [empresa: empresa]
            return
        }

        redirect action: 'list'
    }
}

Claro, se liga só...!

@Transactional
def save(Contrato contratoInstance) {
    contratoInstance.usuarioInclusao = 1L
    if (contratoInstance == null) {
        notFound()
        return
    }
   ?contratoInstance.usuarioInclusao = new Usuario(id:5) // Só pra mostrar...
    if (contratoInstance.hasErrors()) {
        respond contratoInstance.errors, view: 'create'
        return
    }
    
    //contratoInstance.save flush: true

    request.withFormat {
        form multipartForm {
            flash.message = message(code: 'default.created.message', args: [message(code: 'contrato.label', default: 'Contrato'), contratoInstance.id])
            redirect contratoInstance
        }
        '*' { respond contratoInstance, [status: CREATED] }
    }
}

Saca que o hasError tem o respond, e o return! Eu to ligado que eu posso tirar ele, mas queria só saber se tem algum jeito mais elegante de bypassar essa first phase validation!

Como você alterou as propriedades do objeto, convém chamar o método validate() para revalidar o mesmo:
def save(Contrato contratoInstance) {
contratoInstance.usuarioInclusao = 1L
if (contratoInstance == null) {
notFound()
return
}
?contratoInstance.usuarioInclusao = new Usuario(id:5) // Só pra mostrar...
if (!contratoInstance.validate()) {

Saquei, beleza! Brigado meu brother!