Diferença entre DTO e ViewModel?

Lá na pergunta sobre DTO já tem uma boa resposta sobre o que ele é, exceto pelo fato de falar em campos como se fossem atributos, mas é um erro que 99,99% das pessoas cometem mesmo :).

Vamos esquecer um pouco, e só por um momento inicial, a terminologia usada no MVC para não confundir. Vamos usar a terminologia do banco de dados que é mais comum as pessoas entenderem.

O DTO é uma forma de organizar informações na aplicação que vem de alguma(s) fonte(s), geralmente um banco de dados, mas pode ser outro mecanismo. Podemos entender o DTO como uma view que você já deve conhecer do banco de dados. Não que seja exatamente isto, mas só para entender. O DTO pega dados da fonte de dados e monta um objeto fácil de usar usado pela aplicação. Em geral o DTO faz um mapeamento simples e não tem comportamento. Ele tem relação direta com a fonte de dados, e pode ser usado em diversas partes da aplicação apenas para consumo.

Geralmente quando este tipo de objeto tem comportamento ele passa ser um padrão chamado de Active Record. Em alguns casos usa-se o Domain Object ou outra terminologia com pequenas sutis diferenças.

O DTO pega os dados de uma fonte, provavelmente uma tabela de um banco de dados, e monta um objeto simples. O AR permite ter uma lógica de como a transferência será feita, e até mesmo lógica de negócios nela, ainda que alguns autores indicam que aí já seja outra coisa.

O DTO é um mecanismo que pode ser usado como parte do modelo do model do MVC, mas geralmente é o AR que é usado.

Não gosto da pergunta sobre DTO e view model, acho que está confuso, provavelmente errado e segue uma linha específica de desenvolvimento que eu não gosto. Vou ignorá-la.

Continuando na analogia com banco de dados o view model, é como se fosse uma view de um banco de dados que você já conhece, porém apenas dentro da sua aplicação. Ele é um modelo para a view do MVC. Ele não é um modelo para a base de dados. Claro que ele terá que se comunicar com o modelo da base de dados para pegar dados, mas o consumo é da view do MVC.

Há muitos casos simples que usar um objeto via DTO, AR, DO, ou o que seja adequado e simples, há uma relação fácil entre esse objeto e o que vai usar na view do MVC. Mas há casos que não é tão simples, você precisa de objeto que será consumido pela view que é mais complexo que é composto por um subconjunto de campos desses objetos que se ligam à base de dados, ou de campos criados só nesses objetos porque a base de dados ou objetos da aplicação não os provê, ou ainda precisa de dados que estão em diversos objetos e fica complicado usá-los separadamente, então compila-se (no sentido de juntar, não de analisar um código fonte :) ) tudo isto em um objeto que se encaixe na demanda da view do MVC. Ou seja o view model mapeia para a view do MVC, enquanto que o model mapeia com a base de dados.

Então o view model é como se fosse um SELECT pré-estabelecido que gera um objeto pronto e fácil de usar na view.

Não há qualquer relação entre os dois. Achar que o DTO é um mecanismo do view model, na minha concepção, é errado, mas é possível fazer essa analogia como um DTO entre o modelo do MVC e a visão do MVC.

Se não tem uma view na jogada, não tem porque usar um view model. E view pode ser de um padrão de projeto conhecido como o MVC, MVP, ou MVVM, e provavelmente em RUI (que eu ainda estou estudando, e parece bom), mas podem ser views fora desses padrões conhecidos, tem gente que usa um M(odel)V(iew) e um model view pode ser útil mesmo em casos assim.

DTO é um mecanismo primitivo. Sozinho, em sua essência, ele é útil em aplicações simples e diretas. É quase impossível ter uma aplicação com base de dados que não tenha alguma forma de DTO ou suas derivação, geralmente um AR, mesmo que não pareça, já que há linguagens e frameworks que abstraem isso para você. O viewmodel não é necessário a não ser que o mecanismo que se comunica com a view exija, o que é comum nos frameworks MVC por aí, mas é mais por deficiência deles.

Pra fica claro, o model do MVC é sempre uma forma, quase sempre mais sofisticada, de DTO, em geral até mais sofisticada do que um AR. Muitas vezes o model é representado por um repositório, que é cheio de ARs e outros mecanismos.