You'll have to forgive me since, while I know something about NAV web services, I know next to nothing about Sharepoint and BCS.
However, having said that, I do have a few pieces of advice that might be helpful: first and foremost, NAV web services are built on WCF and use the BasicHttpBinding. If you do some research on how to connect a WCF BasicHttpBinding service to BCS you might get some traction there. There is no fundamental difference between any standard BasicHttpBinding service and a NAV-specific web service.
You also mentioned that you were able to successfully connect to NAV web services in Visual Studio using a web reference. However, web reference proxies are built using the older "wsdl.exe" utility, and as such are only capable of working with classic SOAP web services. While BasicHttpBinding services are fully backwards-compatible with SOAP web services, there is still the issue of missing configuration settings that are unique to any WCF service. You really might want to consider using a service reference in visual studio and figuring out how to get it to work correctly with your published NAV web services. With that you can use the generated configuration settings to hopefully get a sense of what is missing in the sharepoint designer. My guess is the missing "endpoint configuration" error is telling you, in so many words, that some WCF-specific settings are necessary in sharepoint designer before you can connect to the NAV web service using a WCF proxy. It could be in the area of security for instance, since WCF gives you a much more granular level of control than classic SOAP. Again, the key I think is remembering that sharepoint needs a properly configured WCF endpoint whereas older web references do not. That's probably why you can get it to work in visual studio and not in sharepoint designer.
Just to give you an idea (not a lesson in "best practices"), when I create a service reference proxy in my NAV projects I often try to go with code-based configuration instead of the overly verbose file-based configuration (especially since we can't control the NAV service-tier endpoint bindings anyway). I use code similar to this to create a client connection (of course this is just pseudo-code and won't compile, you'll need to point to an actual service reference client proxy class for example, but this should give you an idea which WCF binding configuration parameters are necessary):
using System.Security.Principal;
using System.ServiceModel;
private void TestNavConnection(string url)
{
using (var ws = new NavServiceReference(GetBindingTransportCredentialOnly(), new EndpointAddress(url)))
{
ws.ClientCredentials.Windows.AllowNtlm = true;
ws.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation;
var record = ws.Read("XYZ");
}
}
private static BasicHttpBinding GetBindingTransportCredentialOnly()
{
var binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
binding.MaxReceivedMessageSize = 1048576;
return binding;
}
Hope this helps. Good luck!