Чтобы просто добавить любой произвольный класс на любой узел, можно воспользоваться cls: cls: 'buttons__smallButton_red'.

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

Задача-то самая простая. Допустим создать блок на уровне common отвечающий только за цвета на сайте. Назовем его к примеру siteColors. И создать к нему модификаторы типа orange -> hoverOrange -> activeLinkOrange -> activeButtonOrange и т.д. И дальше применять к элементам следующее mix : {block : 'siteColors', activeButtonOrange : true}

В данном случае я бы оставил и класс самого siteColors как минимум из консистентности с самой идеей модификаторов — они должны модифицировать что-то базовое (пусть на данный момент в базовом siteColors и ничего нет). Переживать о лишней разметке особо смысла нет — gzip все пожмет.

Но если очень хочется, то cls таки поможет.

Понятненько. Просто интересно, а грубой ошибки проектирования нет, если я выношу цвета в отдельный блок?

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

Пробовал установить под семеркой enb-sass - ничего не вышло. Требует установки какой-то среды (очень известной, то ли NET, то ли еще что-то в это роде, название в голове вертится, но точно не помню, сейчас пишу из XP), которая итак стоит по дефолту. О, кстати, есть ли еще какая-нибудь технология sass вроде enb-sass? Не хотелось бы городить чего-то лишнего.

И еще: под XP вообще ничего не собирается. (node) util.error is deprecated. Use console.error instead. и т.д.

В project-stub из коробки есть поддержка Stylus (и bem-components активно его используют).

В целом должны быть плагины для сборки практически для всех пре- и поспроцессоров (например, enb-stylus, enb-less, enb-postcss). Но вот с поддержкой Windows действительно могут быть шероховатости. Про них стоит заводить issues в соответствующие репозитории.