Seeing that a callback argument is required, I would say it is not intended. It’s apparently possible to not use add_settings_field() and only register the setting, then provide the equivalent markup in the template. I can see the logic in such an approach. The fact that it works means we can’t really say it’s not supported.
But I think doing so really violates the intention of the Settings API in providing a modular, abstracted, expandable settings interface. I would encourage the use of the intended callback system over a dedicated markup page. It may not be as bad as it sounds. Through the use of the $args parameter, it’s conceivable to build a large settings page with only a few defined callbacks.
I can’t backup my assertions with documentation, all I know is what’s in the Codex and the source code, which you’ve probably seen. The fact that add_settings_field() exists at all, and there is no suggestion at all of not using it makes the intention clear to me. Keeping markup separate from code certainly appeals to my sense of order, but it makes things difficult for anyone wishing to cleanly expand on my work. Adding even more settings is limited to where the do_settings_fields() call is made. Adding settings to the static markup would require a dirty hack.
