Perfectamente:

call ecx

De nadas 

¿Seguro que no?

Fijate que hace entonces esto:

mov ecx, offset BG

Ademas de la etiqueta podes usar esto para la instruccion actual:

mov ecx, $

Aca vamos, siendo el numero eax, en la sección de datos:

buff db 16 dup (0)
format db "%d", 0

invoke wsprintf, offset buff, offset format, eax

Tenes que transformarlo a cadena primero ... podes usar la API wsprintf si queres (pasandole como parametros un buffer, el formato "%d" y el numero).

¿Estas buscando offset bg?

Te falta el . antes del 386 

Nop, los compiladores llevan años y años de optimizacion encima.

Que tenga soporte para macros no cambia nada, las macros son traducidas directamente a lo que equivalen en assembly (y eso lo escribis vos u otro programador). Pero no quiere decir que tus programas sean mas rapidos, el compilador es una herramienta escrita por expertos muy dificil de superar. Normalmente los programas reservan mucha mas memoria de la que ocupan en disco con lo cual es irrelevante el lenguaje en que esten escritos, es decir si tenes un programa de 2KB y otro de 50KB pero los dos reservan 1GB de memoria virtual ... esos 48KB no tienen la mas minima importancia.

Si, el loader al menos tiene que ser de 16 bits.

MASM es Microsoft Macro Assembler, podes aprovechar los macros o no 

Te recomiendo el paquete MASM32, es el ensamblador oficial de Microsoft mas las cabeceras necesarias para la API de Windows, muchisimos macros utiles y el que mas recursos (tutoriales, documentacion, ejemplos, etc.) tiene.

El primero que mencionas no lo conozco, MenuetOS si (salvo la version de 64 bits claro y todos necesitan un boot en 16 ya que la maquina bootea en modo real como si fuera una 8086).

De nadas, mas que nada lo digo para que no inviertas tiempo haciendo el codigo seguro por ejemplo, con que mas o menos vaya es suficiente para que comprendas en ese sistema.