Je pense avoir compris.

Les VLAN sont activés sur les commutateurs (ou ponts) (c'est le concept original). De plus, toutes les cartes réseaux ne supportent pas la technologie VLAN.
En outre, l'architecture DSA permet de caractériser les ports d'un commutateur comme différents périphériques réseaux. Sur mon BPI R3, mon commutateur
est relié à une carte Ethernet. Le SFP n°1 est relié à une autre carte Ethernet. Le pont br-lan permet de relier différents ports du commutateur alors que
le pont br-wan permet de relier le port « wan » du commutateur à celui du SFP n°1 « eth1 » qui n'est pas « relié » à l'origine au commutateur (il y a deux
cartes réseaux).

Il semblerait donc qu'il soit souhaitable de créer deux ponts. Pour créer un VLAN 832 sur l'interface WAN (VLAN FAI) il faudrait seulement activer le filtrage
VLAN sur le pont br-wan. En d'autres termes, il faudrait utiliser la fonction generate_bridge_vlan directement dans le script /bin/config_generate
sans définir le paramètre bridge dans /etc/board.json (ne pas invoquer la fonction ucidef_set_bridge_device dans le script /etc/board.d/03_box).

Finalement, j'ai trouvé comment procéder pour définir l'adresse MAC de mon BPI R3 (carte de développement).

C'est une variable d'environnement U-boot qui va initialiser l'adresse MAC au premier amorçage de la machine.
La variable d'environnement porte un nom correspondant à l'expression régulière eth[0-9]*addr. Aucune
variable d'environnement ayant ce nom n'est définie sur le BPI R3 car c'est une carte de développement. On
peut définir une variable d'environnement U-boot en ligne de commande avec U-boot (durant l'amorçage) ou
avec un utilitaire en ligne de commande disponible sur OpenWrt. Cette variable doit porter une adresse MAC
mais l'assignation n'est que temporaire (mémorisée dans la RAM). On peut l'enregistrer dans une mémoire
non temporaire mais on ne peut lui assigner une valeur qu'une seule fois.

ethaddr

    Ethernet address. If CONFIG_REGEX=y, also eth*addr (where * is an integer).

These variables can be set only once (usually during manufacturing of the board). U-Boot refuses to delete or overwrite these variables once they have been set, unless CONFIG_ENV_OVERWRITE is enabled in the board configuration.

Source : https://docs.u-boot.org/en/latest/usage/environment.html

On peut spécifier des variables d'environnement dans un fichier de configuration U-boot.

L'information qu'il me fallait se trouvait dans l'option CONFIG_DEFAULT_ENV_FILE. Elle est définie dans un correctif
BPI R3 (uboot-mediatek/patches/430-add-bpi-r3.patch). Sa valeur est bananapi_bpi-r3_sdmmc_env. C'est dans
ce fichier qu'on peut ajouter la définition d'une variable d'environnement U-boot ethaddr. Il faut donc faire un
correctif pour modifier ce fichier. À tout hasard, je recherche dans le correctif la chaîne de caractère _env. Bingo !
La configuration bananapi_bpi-r3_sdmmc_env est créée à partir de zéro. Il suffit de modifier le correctif
lui-même grâce au mécanisme de correctif intégré à Buildroot « Quilt ».

Il y a une fonction add_group_and_user définie dans /lib/functions.sh.

local rusers="$(sed -ne 's/^Require-User: *//p' $root/usr/lib/opkg/info/${pkgname}.control 2>/dev/null)"

Cela fait référence à un chemin d'accès à un fichier dans un paquet OpenWrt. Dommage ! On ne peut pas l'utiliser littéralement dans uci-defaults.
J'ai l'impression que l'utilisateur peut être amené à remplir malgré lui un rôle de développeur dans sa quête du graal (routeur pré-configuré, personnalisé
et durci).