The generic answer to this question is yes, the VBUS (+5V from cable) must be connected to the device even if it is self-powered. The reason is as follows:
To start the connect process on host side, the device must pull up D+ (in case of FS/HS mode), or D- (in case of LS device).
However, USB specifications have a mandatory requirement that no USB device should source any current on any interface pin unless it is connected to a cable, see section 7.1.5.1, which reads,
The voltage source on the pull-up resistor must be derived from or
controlled by the power supplied on the USB cable such that when VBUS
is removed, the pull-up resistor does not supply current on the data
line to which it is attached.
If a USB device doesn't have this control, one of data lines will be a source of current. Premature assertion of pull-ups were a source of problems for some legacy USB hosts. That's why this rule was instituted, and there is a special test for this in USB-IF certification program.
Therefore, the USB VBUS is an important "side-band" signal in USB connect protocol. As such, normal USB device ICs do have a separate input pin to sense the presence of USB host. Some IC manufacturers (e.g. FT232H, MCP2221, etc.) skip on this requirement, assuming that their chip will be solely used in bus-powered configuration, where the pull-up control requirement is automatically satisfied. However, when designing these chips into self-powered designs, some extra circuit efforts are needed to link the enabling of pull-ups with presence of VBUS on the USB port.
Regarding the USB connect "handshake" protocol, USB doesn't rely on current drawn from VBUS. The protocol is this: Host port must have VBUS active; VBUS is connected to device; device sees the VBUS and pulls-up 1.5k on one of D+/D- wires; host sees this connect, and after a 100ms delay asserts USB_RESET signaling (SE0 etc.).
The basic "Centronics" printer port protocol uses a simple 2-wire handshake in which the PC asserts a strobe signal until the printer asserts an acknowledge signal. This repeats for each byte transferred.
If you want to "bit-bang" individual pins on the parallel port, you can't use the Windows printer drivers; you need to access the hardware at a lower level. If you're using a USB-to-parallel converter, you'll have to read its documentation.
Best Answer
With standard spec-compliant USB, no. The device must detect the 5V from the host before it's allowed to connect its pull-up resistor to the data lines. If you're building a custom device you can probably keep the resistor on all the time, which will fail USB certification but should still work on Windows.
If you want to connect two devices together, again the answer is no. One side of the connection has to be a host (master), and the other side has to be a device (slave). The host has to enumerate the device by requesting its hardware descriptors and selecting an operating configuration. The host starts all data transfers, so two devices will never spontaneously talk to each other. If you're building custom devices with custom firmware, you can have one device act as a host, if your USB controller hardware supports it.
USB is intended for connecting plug-and-play peripherals to PCs. Another protocol would probably be more useful for whatever you have in mind. Your options will depend on the desired data rate and any special needs you might have.