Selecting, Zooming, and Panning
You pretty much have the right ideas. The Windows User Experience Interaction Guidelines provide standards for this. For example, page 437 specifies:
Single-right-click opens the context menu.
Double-click (left or right) selects and performs the default command.
Single-shift-click (left or right) multi-selects a range; that is, it selects everything between the current selection and where the user clicked (in a rectangle, in your case)
Single-ctrl-click (left or right) discretely multi-selects; that is, it selects or deselects while maintaining the selection state of anything else.
There are rational responses to ctrl and shift double click too.
Page 438 specifies that, if you have scrollbars, then:
Wheel alone pans vertically.
Ctrl-wheel-up zooms in.
Ctrl-wheel-down zooms out.
Tilting the wheel pans horizontally
(I didn’t know about the tilting thing, did you? It doesn’t seem to work with my mouse, even though it’s a relatively new one made by Microsoft. If tilting is not available to a lot of your users, you could try supplementing tilting with Shift-wheel, although you’d need to run a usability test to see which way is left and right –or if users even agree on which way is which).
In one app I use, scroll-wheel zooming zooms in on the point where the mouse is hovering, something I found to be discoverable and very convenient for quickly zeroing in on a specific part of the image. The same app uses shift-pressing of the scroll wheel to pan by dragging, which may make a nice supplement to rolling/tilting the wheel, allowing the user to pan diagonally (the app is 3-D modeler where unmodified pressing and dragging rotates the scene).
Microsoft also specifics that the accelerator keys Ctrl + and Ctrl – zoom in and out, which is probably good for accessibility. In your case, maybe un-modified cursor keys could pan when nothing is selected.
Use of accelerators and the mouse wheel should be considered expert shortcuts, which implies:
There is a more discoverable if less convenient way to do the same actions (e.g., with the scrollbars and menu items).
It’s not necessary for every user to discover and use these features, although the more that do the better.
I don’t believe there is one standard or convention for connecting elements. Your solution isn’t bad, actually. It’s got good discoverability and it’s relatively fast. The main disadvantage I can think of is that it could add too much clutter with all those buttons appearing. What happens if two elements are so close the buttons of one occlude the other? It's also a bit "modey," but with some usability testing, I think you could get it to work acceptably.
One alternative is that instead of a button, a small “hook” (maybe even a visual hook) appears on a selected element alone, and the user drags the hook to another element to connect them. This is perhaps not as discoverable, but it is less cluttering, and it’s analogous to having “handles” to resize elements (which you may also have), so experienced users may still find it quickly. I think I've seen solutions similar to this in certain entity-relations diagramming software, and it's similar to certain types of drawing elements in MS Office (e.g., callouts).
Another option, which is commonly done, is to have a separate pointer tool for connecting. Just as you have a tool for regular selecting, and a tool for zooming (in addition to the mouse wheel), and tools for creating each element, you also have one that, by dragging from one element to another, allows the user to connect elements. This is possibly more discoverable than the option above because the user can see the tool on the tool palette. However, like any use of pointer-tools, it's a bit modey, making it harder to transition back regular selection (or make multiple connections).
As for apps to imitate, look at what your users use now. You also may want to look at MS Visio and MS Project. They're relatively commonly used (and commonly imitated) diagramming apps, so your users might expect your app to work the same way.