Not sure I'm understanding you correctly - by captive portals do you mean the "challenge" that renders in a browser/webview context, commonly when joining a new network?
I'm not sure that would be suitable for what I describe above.
What makes LittleSnitch/Lulu/similar nice is they listen for "all" outgoing traffic types TCP/UDP/ICMP/etc, and show UI immediately, including for non-browser apps, e.g. games, VoIP, P2P apps, whatever -- it tends to be covered. Unless I'm mistaken I don't believe a captive portal can be triggered when "just any" process originates traffic.
That's the strength of LittleSnitch/similar, but the major weakness with host-level filtering they rely on, is you're 100% at the mercy of Apple's networking stack, and this Sonoma issue isn't the first time Apple moved the goalposts. Not too long ago Apple exempted their own services from whatever LittleSnitch hooks [1] and it could of course happen again with any macOS update.
In my view this is precisely why a separate box is appealing. Ideally it'd have as tight of a UI as the incumbent apps, including the same metadata (process name + app icon, protocol, port #, most recent previous attempt, etc).