не понял, что ты хочешь сделать
для того, чтоб поменять внеший вид кнопки, надо задать ей Template в качестве ControlTemplate с ContentPresenter'ом внутри, свойства ContentPresenter'а можно не обьявлять, так как по умолчанию для ContentSource идет Content.
Если свойство контрола с заданным представлением можно задать через ContentSource для ContentPresenter'а

Вообще в работе, UserControl'ы я не использую вообще, это дерьмо. UserControl по сути, это ContentControl, который содержит в себе ContentPresenter. Если мне надо свой контрол или переопределить кнопку, я просто создам класс базирующийся на Button или BaseButton или ContentControl, а если мне содержимое не требуется, то просто Control.
Задам ключи стиля по умолчанию, если мне это нужно.
И добавлю или изменяю поведение контрола.
Зачем UserControl в WPF я не знаю, мне не понятна в чем его +сы.

для того, чтоб не было проблем ресурсами, в проекте в котором лежит мой Control есть папка Themes с файлом Generic.xaml в котором и хранятся все ресурсы для данного контрола.
По сути Control или UserControl\ContentControl, не должны ни чего знать о ViewModel, все его состояния и значения должны определяться в DependencyProperty или Property через соответствующие значения.
А уже потом мы этот контрол применяем в шаблоне DataTemplate, для соответствующей модели, у это шаблона для связывания с соответствующей моделью это DataType. В шаблоне мы имеем полный пакет триггеров ) Легкое связывание, за счет IntelliSense, ведь тип нам известен.
Кстати, если тип объекта Generic, задать тип не получится, но я использую интерфейсы, при этом реализация самого интерфейса Generic объектом не требуется, ведь Binding всё равно работает через рефлексию. Достаточно описать в интерфейсе "контракт" на заданный шаблон данных и можно делать и то и другое раздельно.
UserControl это путь в обратном направлении, это вынуждает нас привязывать Control к модели представления, что как по мне, не является полезным, перенести такой UserControl для работы в другом месте геморой или вообще будет невозможным.
+ UserControl это лишние элементы в визуальном дереве, сейчас направление в WPF именно на снижение размера визуального дерева, чтоб не было 100500 ContentPresenter'ов друг в друге.
+ не забывай, что UserControl и ContentControl, довольно низкоуровневые контролы, а иногда на много полезнее делать Visual Control'ы, где всё их навороты не очень то и нужны.

Но я ни кого не агитирующую, делай как считаешь нужным )

Shocker.ProRoman Mejtes,

Ну вот, я начал новый проект и стал применять твой подход с шаблонами, добавленными в ресурсы по ключам-типам. Тем более, что в 2017-й студии теперь визуализацию при редактировании xaml-а можно смотреть прямо в запущенном приложении.
В принципе удобно, оказывается для ItemsControl и TreeView можно даже и не задавать шаблон Item-а вообще - он его автоматом найдет в ресурсах по типу.

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

Во-вторых, не могу добавить в один словарь DataTemplate и HierarhicalDataTemplate с одинаковыми ключами. Можно, конечно, на разных уровнях их объявить, но это не очень удобно, к тому же ListView, к примеру, норовит забрать HierarhicalDataTemplate, если тот ему попадется первым.

Ты решал как-то эти проблемы или ты с ними не сталкивался?

я не использую HierarhicalDataTemplate, для иерархии я использую DataTemplate'ы

Использовать такой подход повсеместно совсем необязательно .
Есть класс Person, есть шаблон с ключом {x:Type Person}, но если мне надо какой то отличный от стандартного шаблона, я просто указываю его явно и определяю с соответствующим именем. Стандартный тип для такого типа просто отображает, например, имя, фамилию и иконку.

Так же ресурсы можно переопределять в визуальном дереве. То есть в 1 месте ключ {x:Type Person} вернёт 1 шаблон, в другом другой. Поиск ресурсов лучше начинать с того контрола, для которого вы получаете шаблон.

С интерфейсами не получится. GetType() возвращает конкретный тип, а не интерфейс. Это же касается и наследования, для таких случаев вам надо будет явно обозначить шаблон. При этом, вам не кто не запрещает в качестве ключа указать тип интерфейса. Если это действительно нужно.
Я не использую концепцию автоопределения шаблона, практически всегда явно указываю ключ шаблона, но там мне не нужно думать, какой там ключ у этого ресурса , искать его и проверять на точное соответствие строк, я уже знаю, что этот ключ такой же какой и тип у объекта и для его ввода мне достаточно IntelliSense.

Автоопределение я использую только в окнах, для классов наследованных от BaseWindowViewModel.
К слову, я даже не знал, что ListBox сам опредлят тип, потому, что всегда его указывал явно

Сон Веры ПавловныRoman Mejtesя не использую HierarhicalDataTemplate, для иерархии я использую DataTemplate'ы
А это как? можно пример?
Я готовлю маленькую статью на эту тему :( готово процентов на 50, когда закончу пока не знаю, давно обещал
Суть в том, что на базе представления коллекции иерархия разворачивается в список, для отображения дерева можно использовать любые списочные контролы. То есть добавить дерево можно в combobox, listbox, datagrid с минимальными затратами и переработками. работает быстрее, поддерживает мультиселект, иерархические команды, вставку элементов в любую ветку и многое другое.

я уже писал про эту багу, не очень в курсе про TreeView, но думаю там всё работает точно так же
Если включена виртуализация, то элементы списке ListBoxItem и TreeViewItem будут существовать только те, что находятся в области видимости (ViewPort) и элемент который находится в фокусе .
Я это обходил опять же через ICollectionView в котором использовались обёрточные классы для реализации IsSelected свойств, в нём указывал какой тип выделения используется и если это Single селект, то при выделении другого элемента он снимал выделение с ранее выделенного. По сути это дублирование операций в выделением, крайне неприятная реализация, так как вносит путаницу и при изменении типа выделения нужно контролировать в 2 местах этот параметр. По другому никак, либо отключать виртуализацию. Так как объекты находящиеся за рамками ViewPort'а не существуют , значит и их связывания с моделью не существуют. Такой вот неприятный баг.
Вот похожее описание вашей проблемы https://stackoverflow.com/questions/37541929/extended-selection-mode-virtualization-and-isselected-binding