that might be a bit limited to have a captive portal on the FortiGate directly.
The "replacement messages" contain the pages which you can replace/adapt.
The URL to the captive portal, if hosted o the FortiGate is not interesting. The Clients browsers, and even OS do background captive portal detection with unencrypted HTTP pages, for example http://detectportal.firefox.com. This causes in a correct flow:
1) DNS query for the external IP
2) HTTP request to the external IP
3) FortiGate will block this request and send an HTTP 303 or 302 to the client with the content of the captive portal URL (its own interface IP with port 1000 (HTTP) or port 1003 (HTTPS)) - alternatively you can configure an FQDN for this (config firewall auth-portal).
4) DNS query for the FortiGate FQDN (if defined)
5) HTTP request to the IP - captive portal open
6) authenticate and/or accept disclaimer
7) Pass through with your user group or accepted disclaimer. The users will be visible with groups in the users' dashboard on GUI (or CLI "diag firewall auth list")
If you use an auth-portal address it is also crucial that your client is able to resolve the FQDN that you provide there, otherwise 4) will fail.
Important is that you allow DNS for the end user to fulfill 1).
Either exempt the service DNS, or create a guest Wi-Fi > Internet policy with service DNS and a CLI only option "set captive-portal-exempt enable").