Боролся с этой же проблемой, а именно: пытался заставить EF понять что возвращает SP. И выяснил вот что: при мапировании модели EF получает метаданные о SP, из которых выбирает что-то одно. Т.е. если SP возвращает несколько НД (не говоря о коде возврата, который возвращается всегда), то EF "распознает" только один из SELECTов, которые есть в теле хранимки - по нему и строится модель (класс) и код контекста. Если SELECT отсутствует (SP использует EXEC), то класс не создается, а в контексте соотв. процедура возвращает int (т.е. код возврата). Для нескольких НД в качестве класса берется только один (обычно - последний). Остальные надо вытягивать ручками, используя ObjectQuery.NextResult, что неудобно ибо нет явной привязки к соотв. модели, - опять-таки в дело вступают "ручки".
И это не единственный недостаток EF (о нем, кстати, явно написано в BOL). Попробуйте "штатными" средствами EF поиграться с транзакциями или "поймать" EXCEPTION с SQL-сервера.

Вывод : используйте EF как костяк своей ORM, но при этом всякие штучки типа обработки нескольких НД, исключений на стороне SQL Server, управление транзакциями и т.д. добавляйте в репозиторий, используя, например, SQLClient

Как-то так :)