Oh je, schlimmes Thema...

Die gute Nachricht:
Für die SMC-B braucht man keine User-ID, korrekt.
Und zu Frage 1:
Bei eAU & Co wird der Anhang vor dem KIM-Versand mit dem HBA signiert. Daher hat die Signatur unter der eAU tatsächlich nichts mit KIM zu tun. Entsprechend spielt die User-ID auch beim (SMC-B-basierten) KIM-Versand von (zuvor) HBA-signierten Anhängen keine Rolle.

Zur User-ID selbst
Eigentlich sollte diese für Nutzer überhaupt nicht angezeigt werden. Sie wird intern von Clientsystemen (wie einem Arztinformationssystem) verwendet, um einen HBA zu adressieren. Das entscheidende dabei: Diese ID wird vom jeweiligen Clientsystem selbst vergeben. Nach neuen Vorgaben sogar jeweils unterschiedlich pro Session! Damit gibt es keine vordefinierten User-IDs, die man irgendwo nachschlagen könnte.
Das bedeutet also konkret: Sie legen die User-ID für ihren HBA im Kontext von KIM (ihrem speziellen KIM-Client) selbst fest. Frei gewählt - nur unterschiedlich für die eventuell eingesetzten unterschiedlichen HBAs.

Die UserID wird im langen String mit den vielen # Zeichen für den POP3-Zugang angebeben:


Im Benutzernamen für den SMTP-Zugang wird die UserID hingegen nicht angegeben.
Diese Benutzernamen legen Sie in der Kontoverwaltung Ihres Mailprogramms fest (Outlook, Thunderbird, PVS-KIM).

Kann sein, dass das bei Ihrem KIM-Client selbst auch noch angegeben werden muss, das wäre in den Konfigurationsunterlagen zu prüfen (liegen mir aber nicht vor).

Der KIM-Client sucht sich die richtige Karte selbst beim Konnektor. Dafür ist die User-ID irrelevant.

Der Ablauf sieht so aus:
Wenn der KIM-Client eine verschlüsselte KIM-Nachricht entschlüsseln will, liest er aus der KIM-Nachricht die ID des Zertifikats, für das die eMail verschlüsselt wurde. Dann holt er sich die Liste aller am Konnektor verfügbaren Karten und prüft, ob die Karte dabei ist, zu der die angegebene Zertifikats-ID gehört. Diese Karte wird dann zur Entschlüsselung genutzt.

Wie man sieht spielt hierbei die UserID keine Rolle.
Warum es sie dann gibt?
Wenn der Konnektor aufgefordert wird Daten mittels einer Karte zu entschlüsseln, muss der Aufrufende erst einmal nachweisen, dass er der berechtigte Nutzer dieser Karte ist. Dazu muss der Nutzer die PIN der Karte eingeben. Damit man nun nicht bei jedem Aufruf zur Kartennutzung (Entschlüsselung, Signatur etc.) dem Konnektor erneut beweisen muss, dass man ein berechtigter Nutzer ist (also dass man die PIN kennt), gibt es einen Mechanismus diese Info von einem Funktionsaufruf zum nächsten "rüber zu retten": Den sogenannten Aufrufkontext (MandantID, ClientID, WorkplaceID) zu dem bei der HBA-Nutzung auch die UserID gehört.
Das aufrufende System vergibt eigenständig eine UserID (die möglichst komplex und damit schlecht zu erraten ist). Diese UserID nutzt dieses aufrufende System dann immer gegenüber dem Konnektor, wenn es mit genau der Karte sprechen will, zu der beim ersten Aufruf mit dieser UserID die PIN eingegeben wurde.
Da jedes aufrufende System gegenüber dem Konnektor eine eigene Systemkennung hat (ClientID) und dazu noch pro System-Nutzer eine eigene NutzerID vergibt (UserID), kann der Konnektor die von unterschiedlichen Systemen und Nutzerkontexten an ihn herangetragenen Aufrufe unterscheiden und erkennen, wo nun noch eine PIN-Eingabe erforderlich ist und wo nicht mehr.

Das könnte eigentlich vom KIM-Client auch selbst verwaltet werden. Die gematik hatte sich aber bei der KIM-Spezifikation dafür entschieden, diese Festlegung bei der aufrufenden Seite festzulegen (also dem Mailprogramm). Das hat für eine PVS-Integration des KIM-Mailprogramms den Vorteil, dass die Nutzeridentifikation (also die PIN-Eingabe je Karte) nachgenutzt werden kann. Der Nutzer also nur einmal die PIN, z.B. für die SMC-B, eingeben muss und diese dann anschließend innerhalb des PVS z.B. für VSDM, eMP,... und eben auch für die KIM-Nachrichten innerhalb des PVS verwenden kann.

Man braucht die UserID zum Senden bei einem HBA-assoziierten Postfach nicht, weil auch diese ausgehenden Mails mit der SMC-B signiert werden!

Warum ausgehende Mails eines HBA-Postfachs mit der SMC-B und nicht mit dem HBA signiert werden?
Das müssen Sie die gematik fragen. Versuche diesen fachlogischen Fehler zu korrigieren, wurden von der gematik geblockt. Dort sieht man das nicht als Bug, sondern als Feature...