Need to reach a low data rate of about 1.5 - 2 MB/min (200 - 267 kb/s)
summary: yes, depending on content, with a good encoder h.264 can look pretty good at 240kib/s video bitrate, at NTSC 720x480p30.

With modern codecs, you don't need to downscale the rez too far.  If there isn't a lot of noise in your source, you're just putting the same complexity into fewer pixels.  You shouldn't encode 1080p at 270kb/s, though :P.  There is overhead to having more macroblocks, and diluting the complexity across too many pixels probably means worse results from quantizing the DCT coefficients.  Lower resolution lets you turn up the CPU-usage knob on your codec while still being realtime, though.

For a test encode, I have a lossless source of the sintel trailer.  (3D animation with fades between scenes, and significant amount of changeless).  So it's probably actually a really bad test case...

ffmpeg -i sintel.y4m -pix_fmt yuv420p -vf crop=1920:816:0:132,scale=640:-1 -ssim 1 -psnr -tune animation -preset slow -b:v 270k 640x272.x264.270k.mkv


That does quite well, with an average QP of 18.03(I) / 23.44(P) / 24.93(B).  SSIM Mean Y:0.9852979, PSNR Global:44.801 at 231.37 kib/s.  (a still section at the end leaves x264 undershooting the target bitrate for one-pass).  I left psy optimizations enabled, so x264 is trying to do what looks best, not what scores highest on SSIM or PSNR.  Just useful as a ballpark figure.

I have a live-action source that's not too noisy.  I picked a portion that just has one actor moving around on stage, everyone else standing still, and no camera motion.  So it might be similar in compressibility to a someone talking while looking at a webcam, in front of a mostly-constant background.  (stuff like this matters a LOT for compressibility).  About 1/3 of the screen is black background.  (so black the encoder knows you can't see anything, and hardly spends any bits, I assume.)

ffmpeg -ss 2410 -t 30 -i vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -c:a opus -b:a 32k -pix_fmt yuv420p -r 30 -vf framestep=2 -ssim 1 -psnr  -preset slow -b:v 240k  2410+30.slow.opus.230k.mkv


Source is 60p deinterlace output, from NTSC DV or something.  Anyway, with those ffmpeg options, it stays as 720x480@30p (with non-square pixels, display aspect ratio = 16:9).  Output looks pretty darn good considering the bitrate, and the singing sounds good, but has some artifacts.  (audio source is not noisy, and there's no accompaniment, just soloist + chorus.)

frame=  900 fps= 35 q=-1.0 LPSNR=Y:inf U:inf V:inf *:inf size=     990kB time=00:00:30.01 bitrate= 270.3kbits/s
video:854kB audio:120kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.635424%
[libx264 @ 0x2400360] frame I:4     Avg QP:22.63  size: 23294  PSNR Mean Y:44.02 U:48.68 V:47.86 Avg:45.00 Global:42.71
[libx264 @ 0x2400360] frame P:239   Avg QP:22.23  size:  2492  PSNR Mean Y:43.64 U:48.67 V:47.52 Avg:44.67 Global:44.47
[libx264 @ 0x2400360] frame B:657   Avg QP:24.97  size:   282  PSNR Mean Y:43.38 U:48.52 V:47.37 Avg:44.43 Global:44.24
[libx264 @ 0x2400360] consecutive B-frames:  0.6%  0.0% 19.0% 80.4%
[libx264 @ 0x2400360] mb I  I16..4: 27.0% 58.0% 15.0%
[libx264 @ 0x2400360] mb P  I16..4:  0.2%  0.4%  0.1%  P16..4: 22.1%  5.1%  6.7%  0.0%  0.0%    skip:65.4%
[libx264 @ 0x2400360] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8: 12.5%  0.4%  0.1%  direct: 0.1%  skip:87.0%  L0:23.6% L1:74.4% BI: 2.1%
[libx264 @ 0x2400360] final ratefactor: 22.98
[libx264 @ 0x2400360] 8x8 transform intra:59.0% inter:71.2%
[libx264 @ 0x2400360] direct mvs  spatial:99.7% temporal:0.3%
[libx264 @ 0x2400360] coded y,uvDC,uvAC intra: 50.7% 48.1% 24.7% inter: 2.8% 5.1% 0.2%
[libx264 @ 0x2400360] i16 v,h,dc,p: 36% 38%  7% 19%
[libx264 @ 0x2400360] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15%  4% 22%  8% 12% 11% 12%  8%  8%
[libx264 @ 0x2400360] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14%  3%  5% 12% 15% 16% 12% 12% 10%
[libx264 @ 0x2400360] i8c dc,h,v,p: 48% 27% 18%  7%
[libx264 @ 0x2400360] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x2400360] ref P L0: 66.9%  8.4% 14.9%  3.5%  4.6%  1.6%
[libx264 @ 0x2400360] ref B L0: 85.5% 10.8%  2.9%  0.8%
[libx264 @ 0x2400360] ref B L1: 92.3%  7.7%
[libx264 @ 0x2400360] SSIM Mean Y:0.9730952 (15.702db)
[libx264 @ 0x2400360] PSNR Mean Y:43.450 U:48.564 V:47.412 Avg:44.498 Global:44.292 kb/s:232.89


And 35fps on my E6600 (2.4GHz dual core first-gen c2duo) is not bad.  If you're trying to live-stream from a phone, you're going to be much more constrained, though.  You could use lower rez or lower framerate (25 fps, or 24, or 20?)

I was actually surprised at how well x264 did with -preset veryfast.  I guess on this content, even veryfast finds most of the same redundancy to eliminate.

frame=  900 fps= 90 q=-1.0 LPSNR=Y:inf U:inf V:inf *:inf size=     994kB time=00:00:30.01 bitrate= 271.5kbits/s    
video:859kB audio:120kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.612045%
[libx264 @ 0x37b6420] frame I:4     Avg QP:21.51  size: 24840  PSNR Mean Y:44.16 U:48.09 V:47.20 Avg:44.99 Global:42.15
[libx264 @ 0x37b6420] frame P:227   Avg QP:21.22  size:  2649  PSNR Mean Y:43.57 U:48.08 V:46.72 Avg:44.50 Global:44.26
[libx264 @ 0x37b6420] frame B:669   Avg QP:22.30  size:   267  PSNR Mean Y:43.32 U:48.04 V:46.67 Avg:44.29 Global:44.02
[libx264 @ 0x37b6420] consecutive B-frames:  0.9%  0.0%  0.0% 99.1%
[libx264 @ 0x37b6420] mb I  I16..4: 24.0% 45.9% 30.1%
[libx264 @ 0x37b6420] mb P  I16..4:  1.4%  2.8%  0.1%  P16..4: 20.9%  4.2%  3.1%  0.0%  0.0%    skip:67.5%
[libx264 @ 0x37b6420] mb B  I16..4:  0.1%  0.2%  0.0%  B16..8:  1.7%  0.6%  0.1%  direct: 2.1%  skip:95.2%  L0:23.9% L1:45.7% BI:30.3%
[libx264 @ 0x37b6420] final ratefactor: 20.78
[libx264 @ 0x37b6420] 8x8 transform intra:60.6% inter:38.4%
[libx264 @ 0x37b6420] coded y,uvDC,uvAC intra: 39.1% 40.2% 10.5% inter: 2.7% 3.1% 0.1%
[libx264 @ 0x37b6420] i16 v,h,dc,p: 73% 11% 13%  3%
[libx264 @ 0x37b6420] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12%  7% 73%  1%  1%  1%  2%  1%  1%
[libx264 @ 0x37b6420] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 13% 14%  5%  8%  9%  8%  6%  6%
[libx264 @ 0x37b6420] i8c dc,h,v,p: 76%  8% 15%  1%
[libx264 @ 0x37b6420] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x37b6420] SSIM Mean Y:0.9737951 (15.816db)
[libx264 @ 0x37b6420] PSNR Mean Y:43.390 U:48.047 V:46.685 Avg:44.343 Global:44.068 kb/s:234.13


bitrate ended up 2kib/s higher, with about the same PSNR, and higher SSIM.  

With -tune ssim to disable psychovisual optimizations (don't do this for real use),
veryfast gets: Y-SSIM: 15.891db, PSNR Global:44.294, kb/s:233.26.
slow gets: Y-SSIM: 16.097db, PSNR Global:44.752, kb/s:232.86

So that's what x264 can do with h.264 High@L3.0 profile, at 0.023 bits/pixel/frame.

tested x265:
ffmpeg -ss 2410 -t 30 -i vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -c:a opus -b:a 32k -pix_fmt yuv420p -r 30 -vf framestep=2 -ssim 1 -psnr -c:v libx265 -preset slow -b:v 240k -aspect 16:9 x265.2410+30.slow.opus.230k.mkv

ffmpeg version N-68044-gb9dd809 Copyright (c) 2000-2015 the FFmpeg developers
  built on Jan 14 2015 23:21:08 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libbluray --enable-libschroedinger --enable-libtheora --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000 --enable-libvidstab
  libavutil      54. 16.100 / 54. 16.100
  libavcodec     56. 20.100 / 56. 20.100
  libavformat    56. 18.101 / 56. 18.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5.  7.101 /  5.  7.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, matroska,webm, from 'vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv':
  Metadata:
    ENCODER         : Lavf56.15.102
  Duration: 01:22:11.94, start: 0.000000, bitrate: 95843 kb/s
    Stream #0:0: Video: ffvhuff (FFVH / 0x48564646), yuv420p, 720x480, SAR 186:157 DAR 279:157, 59.94 fps, 59.94 tbr, 1k tbn, 1k tbc (default)
    Metadata:
      ENCODER         : Lavc56.14.100 ffvhuff
    Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default)
Codec AVOption ssim (Calculate and print SSIM stats.) specified for output file #0 (x265.2410+30.veryfast.opus.230k.mkv) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
x265 [info]: HEVC encoder version 1.4+286-a12080554342
x265 [info]: build info [Linux][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x265 [warning]: --psnr used with AQ on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: WPP streams / frame threads / pool  : 15 / 1 / 2
x265 [info]: CTU size / RQT depth inter / intra  : 32 / 1 / 1
x265 [info]: ME / range / subpel / merge         : hex / 57 / 1 / 2
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-240 kbps / 1.0 / 0
x265 [info]: tools: rd=2 early-skip deblock sao signhide fast-intra tmvp 
Output #0, matroska, to 'x265.2410+30.veryfast.opus.230k.mkv':
  Metadata:
    encoder         : Lavf56.18.101
    Stream #0:0: Video: hevc (libx265), yuv420p, 720x480 [SAR 32:27 DAR 16:9], q=2-31, 240 kb/s, 30 fps, 1k tbn, 30 tbc (default)
    Metadata:
      encoder         : Lavc56.20.100 libx265
    Stream #0:1: Audio: opus (libopus) ([255][255][255][255] / 0xFFFFFFFF), 48000 Hz, stereo, flt, 32 kb/s (default)
    Metadata:
      encoder         : Lavc56.20.100 libopus
Stream mapping:
  Stream #0:0 -&gt; #0:0 (ffvhuff (native) -&gt; hevc (libx265))
  Stream #0:1 -&gt; #0:1 (ac3 (native) -&gt; opus (libopus))
Press [q] to stop, [?] for help
frame=  900 fps= 24 q=0.0 LPSNR=Y:inf U:inf V:inf *:inf size=     998kB time=00:00:30.01 bitrate= 272.4kbits/s    
video:861kB audio:120kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 1.713292%
x265 [info]: frame I:      4, Avg QP:21.87  kb/s: 5097.48   PSNR Mean: Y:43.899 U:48.345 V:47.187  SSIM Mean: 0.968502 (15.017dB)
x265 [info]: frame P:    177, Avg QP:18.74  kb/s: 710.27    PSNR Mean: Y:43.347 U:48.274 V:47.041  SSIM Mean: 0.973469 (15.763dB)
x265 [info]: frame B:    719, Avg QP:20.83  kb/s: 89.99     PSNR Mean: Y:43.113 U:48.231 V:47.010  SSIM Mean: 0.972552 (15.615dB)
x265 [info]: global :    900, Avg QP:20.42  kb/s: 234.24    PSNR Mean: Y:43.163 U:48.240 V:47.017  SSIM Mean: 0.972714 (15.641dB)
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.6% 0.0% 0.0% 0.6% 98.9% 


(Note that I needed -x265-params ssim=1, because the ffmpeg libx265 interface doesn't pick up a lot of the commandline options.)

    slow: 253.245kbit/s fps=1.7  Y PSNR:44.228 unknown SSIM, forgot to turn it on
veryfast: 244.347kbit/s fps= 24  Y PSNR:43.163 15.641dB SSIM.


perceptually, the x265 veryfast output has less blocking than the x264 slow output.  I think x265 looks better.

x264 and x265 both from the git / hg repos, updated Jan 10th.