Using D+ and D- from USB as power source?
Most likely not...

USB output impedance is high. It's designed to match a 90-Ohm differential impedance in the cable. That means there is (the effect of) a resistor in series to match this cable impedance. Driving through that "source impedance" results in a voltage drop that increases with current draw. You will only have the appearance of ~3V when your current draw is almost nothing. After that it will fall quickly. 

This is a microcontroller output curve. This microcontroller is much stronger (voltage drops less for given current) than most dedicated USB outputs, but it illustrates the problem you'll face.



You have limited control

You do not have complete control over the state of the data lines in a USB port. The protocol requires periodic state changes to those lines, for things like checking if the device is connected, enumerating (listing) all the devices on the bus, etc. So if you have a (very) low current device attached and it otherwise works, it will cycle on and off unexpectedly from your perspective as your computer operates normally.

Pull-up resistors interfere with control

USB requires the data line to be pulled high in the nominal case, so it may not be possible to operate (depending on your load and configuration) in a manner where you can turn off the device as doing so would signal to the port controller that something is wrong, or that no device is connected.



Control is packet based

Devices on a USB bus must announce themselves when asked (part of bus enumeration) and if you do not respond correctly, data sent to the port will not actually change the pins (the driver will just send your program an error code instead). USB pins sit behind a bus/port controller and follow a rather elaborate protocol. It's not like a GPIO pin in a microcontroller.

Further, if you successfully communicate with the USB host controller, you will still not be able to hold the line in a dedicated state. Data is transmitted in packets (defined sequences) and the protocol uses a non-return-to-zero encoding scheme, which is not inherently self-clocking. To correct for this limitation, USB controllers enforce a run-length limiting (RLL) scheme that limits the number of 0's or 1' that can come in an uninterrupted chain. That means even if you send all 1's to the USB controller, the line will not stay in that state uninterrupted.