Как задать структуру выходного проекта?

Ну это как бы можно.

Для начала, вы добавляете каталоги, в которых будут лежать ваши библиотеки, в assembly probing path. Для этого отредактируйте ваш app.config, добавьте в него следующее:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="some\subfolder;another\subfolder"/>
      </assemblyBinding>
   </runtime>
</configuration>

(Документация.)

Затем, в свойствах проекта в зависимостях укажите CopyLocal = False:

Затем, в свойствах проекта-библиотеки установите Output Path в каталог, где вы хотите получить эту DLL (для каждого из ваших target platform/processor):

Ну или в post-build step каждого из зависимых проектов укажите вручную копирование куда надо.

Всё, должно работать.

Как советует @Andrew B в комментариях, существует ещё один путь, описанный в документации: подписаться на событие AssemblyResolve, которое отправляется, если .NET не может загрузить сборку из вашего каталога.

Для этого нужен код наподобие такого:

AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolve;

где метод OnAssemblyResolve определён так:

Assembly OnAssemblyResolve(object sender, ResolveEventArgs args)
{
    var name = args.Name.Substring(0, args.Name.IndexOf(","));
    // проверка на то, есть ли загружаемая сборка среди наших статических ссылок
    // взята из https://support.microsoft.com/ru-ru/kb/837908
    // но вам может быть и не нужна, подумайте сами
    if (!Assembly.GetExecutingAssembly().GetReferencedAssemblies()
                 .Any(asmName => asmName.FullName.Substring(0, asmName.FullName.IndexOf(","))
                                    == name))
    {
        // это не assembly из наших ссылок
        return null;
    }
    var applicationDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
    foreach (var subfolder in new[] { @"some\subfolder", @"another\subfolder" })
    {
        var path = Path.Combine(applicationDir, subfolder, name + ".dll";
        if (File.Exists(path))
            return Assembly.LoadFrom(path);
    }
    return null;
}

(Не тестировал.)

Достоинство этого решения — то, что список путей можно изменять динамически, если это вдруг понадобилось.

Недостаток — то, что у вас некоторые сборки будут грузиться в assembly binding-контексте LoadFrom в отличие от обычной загрузки в контексте Load. Типы, загруженные в таком контексте, будут несовместимы с типами, загруженными в обычном контексте. Особенно это может «клюнуть», если у вас в разных местах лежат разные версии одной и той же сборки. [Это может привести к эффекту, когда один и тот же статический класс существует в двух экземплярах.] Будьте осторожны и готовы к неожиданностям! (Вопрос также обсуждался здесь.)

Если ваши сборки приходят с ресурсами, возможно, вам нужно учесть эту модификацию.

Дополнительное чтение по теме assembly binding/load context:

• Best Practices for Assembly Loading
• Suzanne Cook, LoadFile vs. LoadFrom

Для автоматического копирования сборок в целевые каталоги посредством MSBuild посмотрите ответы к этому вопросу.

Но в целом, я бы порекомендовал воспользоваться советом @TomTom и не заморачиваться, а оставить всё как есть. То, что файлы лежат в одном каталоге, пользователь не увидит, если вы правильным образом поместите ярлыки в системное меню при инсталляции (а вы в любом случае должны это сделать).