As far as I am aware, VisualStudio was not meant to be used in the way you describe. That's exactly what Designer is for.
Regarding using the SharePoint Connections aspect of VisualStudio, according to this article on MSDN:
- It is used primarily to browse an existing SharePoint site as a
hierarchical node tree.
- The connection must be local, meaning, VS has to be running on the
same machine that SharePoint is running on (in this case, your VM).
In addition, you must be a Site Collection Admin for the site you are
trying to browse.
- The only real action you can take is to delete nodes from the
tree (i.e. delete items from the SharePoint site).
- The nodes do expose properties, but those properties are read-only.
So it seems like for doing what you want to do -- make small changes to existing pages or page layouts -- Designer is the tool you'd want to use.
If you are creating all brand new pages or page layouts, you could use VisualStudio, but it must be running on a server where SharePoint is running. This may not necessarily be your production SharePoint environment -- a very typical SharePoint development setup is to give devs a VM that is running SharePoint and VisualStudio for them to do the development work on, and then when they are done, take what they have done and deploy it into the production environment.
And that gets to the difference between a Designer development flow and a VisualStudio development flow.
With Designer, you are connecting to a live site, and creating, deleting or modifying already existing items directly in the live site.
With VisualStudio, you prepare a whole bunch of things in VS (not connected to a live site), like pages, web parts, field definitions, content type definitions, custom lists based on your content types, etc., etc. You then take all those things and package them up, upload the package to the site where you want to deploy them, and activate the feature to deploy all the artifacts in one go.
You can then subsequently make small changes to what you had deployed before, but it would follow a similar development flow -- you would make the changes in VS, create a package that has the changes, upload it to a site, and then upgrade the feature to deploy the changes.