On AWS, all private connectivity from serverless compute runs through a network connectivity configuration. The NCC is an account-level object that holds private endpoint rules, and attaching it to a workspace is what routes serverless traffic through those endpoints. Private endpoints from serverless to AWS resources are currently a preview feature, and the error you hit at step 2.2 is the API telling you your account has not been enrolled in it yet.
Your configuration is not wrong; the switch is off on the Databricks side, which is why @iyashk-DB pointed you at your account team.
So the direct answer to your follow-up is that there is no second private-connectivity mechanism hiding behind the NCC. But whether you actually need it depends on what you are trying to reach, and for the most common target you may already have what you want.
If the target is an S3 bucket in the same region as your workspace, you may not need the private endpoint at all. Serverless compute reaches same-region S3 through a VPC gateway endpoint that Databricks manages, so that traffic already stays on the AWS network rather than the public internet. The firewall configuration page under serverless network security shows how to write the bucket policy so the bucket only accepts that path. No NCC private endpoint is involved, and nothing about the preview blocks you.
If the target is anything else, such as a database or an API behind a firewall, the generally available option is allowlisting Databricks' published outbound IP addresses on the resource side. That gives you restricted access but not private connectivity, since the traffic uses public IPs. If you go this way, build the allowlist from the JSON list Databricks publishes rather than hardcoding addresses.
If the requirement is strictly no public path to a non-S3 resource, then the NCC private endpoint preview is the only mechanism, and the account team enablement is the way there. The good news is that once your account is enrolled, your existing setup should carry on from step 2.2 unchanged.
Which resource are you trying to connect to? If it is same-region S3, the gateway endpoint route probably solves this today without waiting on the preview.