Talvez a pergunta não seja necessariamente se se pode jogar regras de negócio no persistência, mas o contrário: se se pode jogar alguma regra de persistência em objetos de negócio. Nesse caso, pode, mas aí não seria mais o padrão DAO, mas o padrão [google]Active Record[/google].
Para esse padrão, uma classe, por exemplo, Vendedor, poderia ter, ao mesmo tempo, regras de negócio, como:
:arrow: String getNome();
:arrow: BigDecimal getPercentual();
:arrow: void adicionaProdutoVendido(Produto produto, Calendar quando);
e regras de persistência, como:
:arrow: void salvar();
:arrow: static Vendedor procurar(Long id);
Uma terceira altenativa ao DAO e ActiveRecord é o [google]Data Mapper[/google], que é bem complicado de fazer, e é mais visto como ferramenta (ex.: Hibernate).
Voltando ao seu problema: fiquei curioso com seu BaseDao, é realmente uma abstração do tipo em que os usuários desta classe não precisam fazer mais nada no que se refere a pesistência? Se pelo menos faz uma boa parte, pode usá-lo como um atributo nos objetos de negócio (composição, não herança!). E sempre que houver a necessidade de salvar dados, basta delegar para esse BaseDao.
Uma última coisa: como você separa Service de Entity? Se essa separação for do tipo: o service tem a lógica e o entity tem os getters/setters, saiba que é uma implementação ingênua. O melhor é quando o service for que-nem um maestro de um concerto: não possui nenhum instrumento para fazer a música, mas tem a batuta para indicar quem e em que ritmo canta. Ou seja, o service não tem regra, nem atributos de negócio, mas conhece os entities certos (que possuem regras e atributos) para fazer o sistema funcionar.