Resposta detalhada, mas discordo sobre se o "SSIS não pode reconhecer o formato de data fornecido na pergunta".
Talvez se fosse reafirmado como "SSIS não pode reconhecer o formato de data fornecido sem ajuda". O problema principal neste caso é que, por padrão, as rotinas de análise de data e número são reconhecimento da localidade . Em geral, isso é uma coisa boa, exceto quando não é. Eu tropecei nisso pela primeira vez quando estava lidando com datas em um formato de ccyymmdd saindo de um mainframe. Como outros indicaram, ele analisará no tsql, por que não no SSIS? Existem muitos artigos por aí defendendo fatiar e cortar os dados da string para torná-lo um datetime válido, mas por que passar por todo esse aborrecimento?
Dado isso como dados de entrada de amostra (delimitado por tabulação).
LongDateDesiresFastParse Gibberish
Oct 25 2011 10:18:10:756PM Hello world
Oct 24 2010 10:18:10:756PM Hello 2010 world
Oct 23 2009 10:18:10:756PM Hello 2009 world
Oct 22 2008 10:18:10:756PM Hello 2008 world
E um pacote que se parece com isso,
Alterando uma configuração na Flat File Source , posso fazer o pacote falhar ou não.
Clique com o botão direito do mouse na Fonte do Arquivo Simples e selecione "Mostrar Editor Avançado". Na guia "Propriedades de Entrada e Saída", expanda as Colunas de Saída e localize a coluna que contém a data. Altere o FastParse configuração de Falso para Verdadeiro .
Quando o executei, o pacote falhou originalmente, pois estava perdendo a precisão ao armazenar esse valor em um
DB_TIMESTAMP . Tive sucesso quando configurei a coluna para digitar DB_TIMESTAMP2 
Pacote de demonstração disponível em https://sites .google.com/site/billfellows/home/files/FastParse.dtsx?attredirects=0&d=1
