Почему не использовали managed odp.net? (Oracle.ManagedDataAccess вместо Oracle.DataAccess). Качаем xcopy версию и ложим рядом с exe: 6mb вместо 100mb. Одна обычная .net сборка (две если нужны распределенные транзакции), не нужно тащить нативные либы, нет проблем с x86 vs x64 и другие плюшки.
В большинстве случаев ничего менять не нужно кроме неймспейса, для ваших задач должно хватить с головой.

Отделять код, конечно, есть смысл, он собственно и отделен. Как пример, класс шифрования в данном случае в отдельном классе. Там много #if внутри, особых сложностей с тестированием не замечено. Что один класс\файл с ифами, что несколько под каждую платформу но без ифов, с точки зрения тестируемости сложностей это не добавляет.
В любом случае юнит\UI тесты запускаются в соотв. контексте. Например под WP тесты гоняются прямо на устройстве\эмуляторе в контексте приложения:

Все правильно, залогиниться под любым пользователем винды просто так не получиться не имея токена или пароля. Разве что LOCAL/NETWORK SERVICE если достаточно прав.

Абстрактный пример:

LogonUser("LOCAL SERVICE", String.Empty, String.Empty, 5 /* service-type logon */, 0, out userToken);
DuplicateToken(userToken, 2, ref userToken2);
identity = new WindowsIdentity(userToken2);
context = identity.Impersonate();
...
context.Undo();

Но можно например спросить креды раз и сохранить токен что бы можно было в дальнейшем выполнять действия от этого пользователя, т.е. как-бы получить у него согласие на такую операцию. Хранить кстати пароль постоянно в такой ситуации нет необходимости. Как пример виндовый шедулер, один раз задаче разрешаем выполняться от любого пользователя и все.

Но тут очень все зависит от конкретной ситуации, если это, например, корп. сайт в интранете, который предоставляет доступ к какой-то информации из своей базы то подмену нужно делать уже после входа и перед получением данных.

Предположим что сайт решает какую именно инфу выгребать, вызывая что то типа WindowsIdentity.GetCurrent().Name. Тогда можно завернуть этот вызов во что-то, что будет возвращать другого пользователя.

Вообще с win auth решение сильно зависит от того к чему нужно получить доступ.

Такой вариант имеет право на жизнь, но потребует куда больших изменений. Особенно если сайт уже готовый. Плюс нужны дополнительные телодвижения, что бы заработали полезные встроенные фишки, например атрибуты [PrincipalPermission(…)].

Также намного больше мест где может закрасться ошибка, что тоже важно. Скорее всего, после таких изменений с существующей системе потребуется еще раз проходить аудит безопасности.